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: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
