On Fri, Nov 25, 2016 at 7:14 AM, Gilles <gil...@harfang.homelinux.org> wrote:
> Hello. > > Thanks for all the replies. > However, it seems that when a project could make use of the > flexibility provided by modularization, there are objections > to really embrace it: > * Some don't like a partial release > * Some don't like different version numbers > * Some don't like releasing codes at different levels of > "achievement" > > Clearly there is no consensus. > > IMHO, a particular useful feature of modularization is to > allow the respective versions to reflect the actual state of > the code contained in the corresponding module. > Otherwise the (single) version is misleading for some of > modules and meaningless for others. > > I can understand that version varying across modules requires > careful attention; but is there a problem in principle? > Won't tools such as Clirr readily spot failures to comply with > compatibility requirements? > > Using again the practical example, and trying to mix and match > opposite POVs, here is a suggestion. > > Release all "productive" functionality: > commons-rng-client-api -> 1.0 > commons-rng-core -> 1.0 > commons-rng-simple -> 1.0 > commons-rng-sampling -> 0.8 > > Question for the latter (from the other thread): > When "sampling v1.0" is released, can it break compatibility > with "sampling v0.8" ? > I guess not. You could also remove any jar hell risk by packaging 0.8 in an .alpha. package. Gary > > Release code only useful for internal development (e.g. > checking that a contribution does degrade performance), > with a suffix that indicates so > commons-rng-jmh -> 1.0-dev > > There is no obligation to provide benchmarking code, is there? > Publishing results on the web site is already much more than > other components do. > > Release usage examples with a version number and suffix > indicating that no comptatiblity is to be expected: > commons-rng-examples -> 0.0.1-beta > > [Is there a better "suffix"?] > > WDYT? > > > Regards, > Gilles > > > > On Fri, 25 Nov 2016 13:34:04 +0100, Jörg Schaible wrote: > >> Hi, >> >> Stian Soiland-Reyes wrote: >> >> I think I'll tend towards agreeing with Jochen here, rather get half the >>> modules out early than fight ourselves with versioning workarounds if the >>> rest of the modules are not ready for prime time. >>> >>> However I see concerns of selective "part releases" and reproducible >>> builds, so I would do this using Maven profiles - the release profile can >>> have a smaller <modules> set. >>> >>> I then think all the modules that appear in the src release should also >>> go >>> to Nexus as binaries, even if they are more exotic "internal" modules. I >>> would not mess around with selective deployment as it is a recipe for >>> maintenance nightmare and manual mistakes. >>> >>> It only gets tricky if the leftover modules get a release cycle of their >>> own. >>> >>> It is OK if the -bin release don't have all modules, that is more of a >>> convenience of jars that are useful out of the box. >>> >> >> The -src artifact is a different case. It should contain anything >> independent of the published modules' artifacts (and it can, because it >> depends on the file patterns in the assembly). It is always a hassle if >> you >> have no direct possibility to fetch the matching source of the examples >> (and >> even the JMH stuff) for an individual release. Directing users to GIT is >> not >> very convenient. >> >> Cheers, >> Jörg >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459> JUnit in Action, Second Edition <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021> Spring Batch in Action <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
