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: [email protected]
For additional commands, e-mail: [email protected]
