commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [RNG][ALL] Official vs "courtesy" code ?
Date Fri, 25 Nov 2016 15:14:47 GMT

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

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" ?

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"?]



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:
For additional commands, e-mail:

View raw message