commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Bourg <>
Subject Re: [RNG] modules vs projects
Date Thu, 29 Sep 2016 10:06:36 GMT
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.

> 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.

> Just to spare one vote every two years?

And multiple projects would hypothetically ease one migration every five

Emmanuel Bourg

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

View raw message