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 Sun, 02 Oct 2016 11:28:49 GMT

On Thu, 29 Sep 2016 11:48:29 +0100, Stian Soiland-Reyes wrote:
> Having all modules in the project have the same <version> is just a
> convention.

That's not what I've been told.
Anyways, I agree that interdependent modules _of the same project_
should preferably share the same version number.

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

Confusing it is.
That's why my preferred option, by far, is to consider that
"rng-core" and "rng-utils" are independent projects, and that
"rng-utils" depends on "rng-core", in the same way that it
will depend on the JDK.

This would also reflect the separation of concern and the
quite possibly different developers teams.
This is a fairly sensitive issue: experience has shown that in
Commons Math, several parts of the library had, de facto, become
the personal turf of a single developer.

I believe that "component" implies an idea of strong integration
(down to the implementation level).

"Commons RNG" should not attempt to become "a framework that
produces random numbers", foremost because that is too vague a
definition for a "component".
Another reason is that it is too ambitious for non-experts (as all
the readers here are, AFAICT).
And yet another is that it exists already:

"rng-utils" could very well depend on other libraries, if the
intention is really to provide extended support to non-Java and
non-Commons-RNG implementations.

What is called "rng-core" here would just happen to provide
pure-Java implementations (and the minimal set of utilities that
is now implemented), and the "UniformRandomProvider" interface.

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

This is fragile indeed.

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


Two separate components would not suffer from that problem.
The release notes of "rng-utils" will mention the minimum
version of "rng-core" compatible with it, as it does for
the minimum version of the JDK.

It is of course possible that a release of "rng-core" could
trigger the release of "rng-utils", but only if the latter
would be broken by the former.

Breaking can only happen if
  * methods are removed to the "UniformRandomProvider" interface,
  * methods are added to the "UniformRandomProvider" interface,
  * the name "UniformRandomProvider" is changed,
  * the name "RandomSource" is changed,
  * methods of "RandomSource" are removed,
  * the external representation of the "RandomSource.State" is

I do not foresee any circumstance where any of those would

However, extend the scope of "Commons RNG" (e.g. to implementations
that would require adding methods in "UniformRandomProvider"), and
all bets are off...

> 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

This is what I find unnecessary disturbing for user of
"rng-core" (i.e. all those applications who need a PRNG
in order use it in a specific way not covered by "rng-utils",
or those applications who want to minimize their dependencies
for whatever reasons).

For separate components, this disturbance does not happen.
Hence I find it a better solution.

> A good question is - if rng-core changes - would the other modules
> need to change as well?

Absolutely not (bugs notwithstanding).
It's exactly like when there is a new Java version, not all
libraries _need_ to use it (obviously none need to).

"rng-utils" can choose when it wants to release a version
that will use all the features of "rng-core".
This could happen if there is some ongoing work in "rng-utils"
that would better be completed before releasing the next version.

It is certainly acceptable that, for some period of time, a
new RNG implementation in "rng-core" will not be supported
by some of the (syntactic sugar) methods of "rng-utils".

Then again, it is not expected that "rng-core" will change
often, once most PRNGs have been implemented.

> If not, then there's not a big reason why they
> need to be together in the same project

My point indeed. ;-)

> (but we would end up with
> Commons Commons Components..)

There you lost me.

> 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

This is indeed what I want to avoid if possible.

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

Do I understand correctly that any "vendor" will force a re-release of
the common interface, whenever they touch their own code, and force a
"no-op" release of all the other vendors' library to keep the versions
the same?

Are there functionalities which a vendor might provide that does not
exist in "commons-rdf-api" and be used by applications?
If not, I'm not sure that the situation is comparable.


> On 29 September 2016 at 11:23, Gilles <> 
> 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:
For additional commands, e-mail:

View raw message