commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [All] "Commons Math" is not a component
Date Fri, 22 Dec 2017 15:03:23 GMT

[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]


[7] There already are some identified issues that would impact the
     stability of the API, e.g.

> Stephen
> On 9 December 2017 at 01:59, Gilles <> 
> 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]
>> [2]
>> [3]
>> [4]
>> [5]

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message