commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [RNG] modules vs projects
Date Wed, 28 Sep 2016 13:58:05 GMT
On Wed, 28 Sep 2016 14:17:19 +0200, Emmanuel Bourg wrote:
> Le 27/09/2016 à 01:14, Gilles a écrit :
>> An additional module in Commons RNG will not help, as was noticed
>> some time ago: it won't be possible/allowed to release the modules
>> separately.
>> I don't want to have to release a major version of Commons RNG
>> just because accessory tools requires it.
>> Users should not wonder with each new version whether there was
>> a bug or a change in the core functionality.
> Multi-module projects are quite common and the case you mention isn't
> unusual.

Please show an example.

> I don't think this is a blocking issue. Even if only one of the
> modules has changed it's possible to publish a new release.

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.

> And if all
> modules evolve continuously a few release processes are saved 
> compared
> to a multi-project approach.

The point is that "rng-core" is not meant to evolve continuously
(as you pointed out yourself, noticing the limited number of RNG
implementations out there!).

When "rng-core" evolves, it is in order to add implementations: a
backward compatible operation that does not require a major version

Each major bump will rightly trigger unrest among users. And
unnecessary work.

Just to spare one vote every two years? [1]

Moreover even if they could change, "rng-core" and "rng-utils"
will only rarely "co-evolve" since
  * adding new RNGs to the former has zero impact on the latter,
  * adding new utilities to the latter has zero impact on the

Moreover, _old_ versions of "rng-utils" could perfectly use
_new_ versions of "rng-core".
With modules, you'd have to re-release "rng-utils", again for

So I would readily bet that a multi-module project will imply
MORE time from the RM and from the voters.

It's always possible to merge two projects and harmonize the
package name and version number.

One the major bump has been done, for no reason (as I showed
above), it cannot be undone.


[1] Wild guess at the average release rate of a Commons component.

> Emmanuel Bourg

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

View raw message