commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stian Soiland-Reyes <>
Subject Re: [RNG] modules vs projects
Date Thu, 29 Sep 2016 10:48:29 GMT
Having all modules in the project have the same <version> is just a convention.

It could make sense to increment the rng-core module more slowly,
while still allowing it in the build.

For instance:

commons-rng 1.2.0 could include:
  rng-core 1.1.2 (nothing actually changed, but we can't re-deploy 1.1.1)
  rng-utils 1.2.0 (new method)

This is a very OSGi-way of doing it - but it will confuse lots of
users as you know have three different version numbers and couldn't do
${rng.version}.  For example - see how httpclient and httpcore have
split apart version-wise - this can be confusing for many as you
generally have to upgrade them together as close friends.

Another alternative would be a more careful hand-holding where
rng-core stays versioned at 1.1.1 in the pom.xml until it changes, but
then this is very hard to verify as you must make sure it is truly
exactly the same as "the other 1.1.1". (And you would have to manually
prune the "newer 1.1.1" from Nexus staging repository - if it even
would allow you to upload a duplicate version).

I would not recommend the option of 'partial module releases' - I've
seen some Apache projects try to do this, but it leads to a very
complicated picture for downstream as you then potentially have to
build many different such "patch releases" to get all the modules. It
also complicates our download/source pages a lot.

The simplest is to always increase the modules together - as we won't
generally bump major.  It does mean perceived incompatibility if appA
uses rng-core 1.1.0 and friends; while a newer version of its
dependencyB now uses rng-core 1.2.0 - and it could look like an
upgrade is required even if rng-core 1.2.0 is line by line the same as
rng-core 1.1.0

A good question is - if rng-core changes - would the other modules
need to change as well? If not, then there's not a big reason why they
need to be together in the same project (but we would end up with
Commons Commons Components..)

BTW - we'll face a similar issue in Commons RDF where we shouldn't
have to increase the version of the commons-rdf-api module when
nothing has changed - but would be forced to do so if we add a public
method in one of the other modules (e.g. in the Jena integration) and
release them all together.

On 29 September 2016 at 11:23, Gilles <> wrote:
> On Thu, 29 Sep 2016 12:06:36 +0200, Emmanuel Bourg wrote:
>> Le 28/09/2016 à 15:58, Gilles a écrit :
>>>> Multi-module projects are quite common and the case you mention isn't
>>>> unusual.
>>> Please show an example.
>> Spring, Jetty, Jackson, Log4j, Hadoop, Lucene, Maven, Hipparchus...
>> There is no lack of examples. Multi-module projects routinely publish
>> new releases with some of their modules unmodified.
> You noted several weeks ago that a Commons component cannot
> release modules with different version numbers.
> The problem is not multi-module; it is two codebases (core
> and utils) having completely independent release cycles.
> Users should be able to stick with "core-1.0", as long as
> there is no change in that module, not forced to upgrade
> to a "core-1.1" because a new release of "utils-1.1" was
> performed.
>>> With modules, the problem I see is (as I already evoked it):
>>> At time t0, publish
>>>    * rng-core v1.1
>>>    * rng-utils v1.1
>>> Some time later, a weakness or bug that cannot be fixed
>>> in backwards-compatible way is identified in "rg-utils".
>>> Hence publish
>>>    * rng-core v2.0
>>>    * rng-utils v2.0
>>> Due to the package change, users that do NOT use "rng-utils" have
>>> to either modify all their code because of the package name change
>>> (although the implementation has not changed one bit) or continue
>>> to use a now unsupported v1.1.
>> True, but that's a very rare case, and there are other ways to mitigate
>> what you perceive as an issue. If we decide in a couple of years to
>> rework rng-utils in a backward incompatible way, we can rename or split
>> it. For example let say we realize its scope isn't well defined or it
>> gets too big, we could extract a "rng-variate" module and rename the
>> remaining one to "rng-tools". This would not affect the users of rng-core.
> Forced upgrade for no reason would not be a rare case:
> Add a feature in "utils" and you force users of "core" to upgrade.
> And the converse is also true.
>>> Just to spare one vote every two years?
>> And multiple projects would hypothetically ease one migration every five
>> years?
> This would happen for _every_ release.
> Gilles
>> Emmanuel Bourg
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Stian Soiland-Reyes

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message