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