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 <gil...@harfang.homelinux.org> 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: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > -- Stian Soiland-Reyes http://orcid.org/0000-0001-9842-9718 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org