Hi.
[Sorry for not replying earlier; I've been quite diverted
by what happened around the RNG-37 issue[1].]
On Mon, 11 Dec 2017 16:16:34 +0000, Stephen Colebourne wrote:
This all seems reasonable. One things I'd suggest is getting at least
one new component to a full release as soon as possible to
demonstrate
that the plan can work.
Except for the "beta" release, a demonstration of that plan has
already been performed, resulting in "Commons RNG"[2]: I extracted
codes from the "random" package of "Commons Math"[3][4], refactored
the API, made a modular project, added functionality and ported new
algorithms from standard implementations in C, increased coverage,
rationalized the test suite, ran benchmarks[5] and external tools[6]
to ensure that neither performance nor correctness was adversely
impacted by the overhaul.
[A beta release was not necessary because the client API was quite
simple and the functionality fairly "shallow" and "narrow" (and test
coverage was over 95%).]
Do you agree that the point was proven?
This suggests that step 1 involves a full
release for [numbers]
Whether to do a "beta" release is a general question on this list.
["Commons Text" had a beta release but I don't remember that it had
been useful, lacking beta-testers, IIRC.]
The ultimate goal is to not waste early the "pristine" (unnumbered)
top-level package name.
Anyways, IMHO, a code review of "Numbers" is quite necessary since
the modules were worked on by different people and not all the details
of the porting were specified.[7]
Regards,
Gilles
[1] https://issues.apache.org/jira/browse/RNG-37
[2] https://commons.apache.org/rng
[3] http://markmail.org/message/uiljlf63uucnfyy2
[4] http://markmail.org/message/422klwpqwclp4ru2
[5]
https://commons.apache.org/proper/commons-rng/userguide/rng.html#a4._Performance
[6]
https://commons.apache.org/proper/commons-rng/userguide/rng.html#a5._Quality
[7] There already are some identified issues that would impact the
stability of the API, e.g.
https://issues.apache.org/jira/browse/NUMBERS-40
Stephen
On 9 December 2017 at 01:59, Gilles <gil...@harfang.homelinux.org>
wrote:
Hi all.
Stephen Colebourne correctly summarized the situation[1]:
Project management must be based on life-cycle, not the
other way around.
Here below, a concrete plan is proposed in answer to the
suggestion (of a fork) made by Martijn Verburg[2].
1. Initial (beta?) release of "Commons Numbers".[3][4]
2. Create separate git repositories for functionalities
that have independent life-cycles and move the codes
out of "Commons Math".
3. Modularize "Commons Math" into
a. A set of "supported" modules: functionalities having
undergone a review in order to define a stable API.
b. A set of "experimental"/"beta" modules: functionalities
that have been modified since the last release (e.g.
bug fixes[5]) but are expected to undergo API changes.
c. A "legacy" module for heavily used functionalities known
to harbour difficult design issues.
4. Initial (beta?) release of codes in category (2) as new
components.
5. First non-beta release of "Commons Numbers".
6. Release v4.0 of "Commons Math".
7. First non-beta release of codes in category (2).
8. Progressively move code from category (3c) to (3b) and
from (3b) to (3a), or to (2). And RERO accordingly.
Do you (PMC, committers, developers and users) foresee any
show-stoppers in the above sequence?
Regards,
Gilles
[1] http://markmail.org/message/w3imqvbf3wphvokj
[2] http://markmail.org/message/rribnh3tiikqtllf
[3] https://git1-us-west.apache.org/repos/asf?p=commons-numbers.git
[4] https://issues.apache.org/jira/projects/NUMBERS
[5] https://issues.apache.org/jira/projects/MATH
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
