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 <gil...@harfang.homelinux.org> 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 >> (<https://issues.apache.org/jira/browse/MATH>). 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: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
