commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <>
Subject Re: Commons-Math release schedule
Date Tue, 27 Mar 2012 15:34:28 GMT
I am -1 to publishing any sort of release schedule to which we would
be held accountable.

On Tue, Mar 27, 2012 at 8:33 AM, Gilles Sadowski
<> wrote:
> Hello.
>> > [...]
>> >
>> > But one question I would like to ask is what is the process for
>> > arranging for a new release of Commons-Math. I ask because we have
>> > 6-month release schedule for our mathematical and utility library, which
>> > makes use of Commons Math, and we would like to see whether we can have
>> > releases of Commons Math that could fit that release cycle.
>> Yes. We have not been very good at this for the last release and it was
>> way too late. However, we do want to be more in line with the "release
>> early, really often" credo.
>> What is most needed is help in resolving the issues that are registered
>> in our JIRA tracking system
>> (<>). Opening new issues also
>> help improving the product, of course, but help in solving them is most
>> wanted.
>> As far as simple issues are concerned, they can be dicussed on the JIRA
>> tracker itself, and patches can be attached (not forgetting to check the
>> box allowing us to include the patch in the main code). Testing the
>> already provided patch and cleaning them so they do have appropriate
>> comments, javadocs and test cases helps. When discussion on issues is
>> too long, it is better to switch the discussion to the developers
>> mailing list, as it is a more appropriate place for this.
>> When the component has reached a state where another release is worth
>> doing, then asking for such a release on the dev list and helping in
>> freezing the code and polishing it is greatly appreciated.
> IIUC, the issue is indeed to have a more objective definition of "component
> has reached a state where another release is worth doing".
> From a user's point-of-view, _any_ improvement, be it a bug fix or a new
> feature, is worth being released.
> In order to "release early, really often", I would thus propose that we
> stick to a time-based release schedule. Every 6 months would be nice indeed.
> [I also think that the shorter the span between releases, the easier the
> pre-release work (code cleanup, etc).]
>> >
>> > We are more than happy to assist in Commons Math releases, if this helps.
> Apart from the "usual" CM work described above, I wonder whether the
> proposed additional human resources could allow parallel development of the
> 3.x (backward-compatible) releases and the 4.0 release.
> Until now, this could not be achieved due to the low number of active
> developers (w.r.t. to the amount of code).
> The advantage would be that some interesting, but compatibility-breaking,
> ideas could be
>  * implemented and tested without delay, and
>  * readily compared with the "stable code".
> Best regards,
> Gilles
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message