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 years? Emmanuel Bourg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
