Hi Jörg.
On Fri, 25 Nov 2016 15:25:09 +0100, Jörg Schaible wrote:
Gilles wrote:
Hi.
The "Commons RNG" component (in the "Apache Commons" sense),
consists of the following modules (in the "maven" sense) that
provide Java code:
(1) commons-rng-client-api
(2) commons-rng-core
(3) commons-rng-simple
(4) commons-rng-sampling
(5) commons-rng-jmh
(6) commons-rng-examples
One could see the RNG low-level "library" as composed of (1),
(2) and (3).
(4) is higher-level; it depends solely on the
"UniformRandomProvider"
interface defined in (1).
(5) does not provide any functionality to application developers.
(6) contains working code that is either of interest to "Commons
RNG" contributors (for running the "stress" tests) or
currently,
fairly trivial (and not recommended) examples of use of the
"library".
Questions:
a. Is it OK if the official release does not contain (5) and (6)?
[Rationale is that it would allow to make changes without
bothering about compatibility with _unintended_ uses.]
b. If so, is it still OK to provide JARs for them via the web site
(but not upload them to Nexus)?
c. Is it OK that the modules have different versions (reflecting
the perceived status of development)?
[This is related to the "commons-rng-sampling" issue of the
post with subject "Ralease policy for version < 1".]
c) does not make much sense to me. Even if we get it out of the door
with
out tooling, how will users find version 0.8 on our web site if it
was part
of release 1.0?
Perhaps what makes sense is to consider that it is each module
that is actually released (through a "bundled vote").
What if we need a maintenance release 0.8.1 ... do we also
need 1.0.1 for the rest?
No (if version numbers are supposed to mean something).
If not, why release it together with 1.0 at all? Or
why not simply have an own component as Gilles requested in first
place?
Sure, that would be a solution in line of current practice.
And in effect letting modules live their own life would have the
same effect.
The choice (module vs component) is then more a matter of community
(i.e. do the same people perform the development of those modules)?
Regards,
Gilles
Cheers,
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
