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

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

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

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.

Gilles

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


Emmanuel Bourg




---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to