I tried to suggest this for our matplotlib development cycle, but it didn't get the roaring response I was hoping for (even though I was being conservative by suggesting a 8-9 month release time): http://matplotlib.1069221.n5.nabble.com/strategy-for-1-2-x-master-PEP8-changes-tp39453p39465.html
In essence, I think there is a lot of benefit in getting releases out quicker. The biggest downside, IMHO, is that those who package the binary releases have to work more frequently on what is not a particularly glamorous task. For those who are worried about the quality of releases being diminished by releasing more frequently, an LTS approach could also work. Good luck on getting these frequent releases going, IMHO there is a lot to be said for having users on the latest and greatest, rather than have users on old versions & still finding bug which were introduced 24 months ago and fixed 12 months ago on master... Cheers, Phil On 14 January 2013 00:19, David Cournapeau <courn...@gmail.com> wrote: > On Sun, Jan 13, 2013 at 5:26 PM, Nathaniel Smith <n...@pobox.com> wrote: > > On Sun, Jan 13, 2013 at 7:03 PM, Charles R Harris > > <charlesr.har...@gmail.com> wrote: > >> Now that 1.7 is nearing release, it's time to look forward to the 1.8 > >> release. I'd like us to get back to the twice yearly schedule that we > tried > >> to maintain through the 1.3 - 1.6 releases, so I propose a June release > as a > >> goal. Call it the Spring Cleaning release. As to content, I'd like to > see > >> the following. > >> > >> Removal of Python 2.4-2.5 support. > >> Removal of SCons support. > >> The index work consolidated. > >> Initial stab at removing the need for 2to3. See Pauli's PR for scipy. > >> Miscellaneous enhancements and fixes. > > > > I'd actually like to propose a faster release cycle than this, even. > > Perhaps 3 months between releases; 2 months from release n to the > > first beta of n+1? > > > > The consequences would be: > > * Changes get out to users faster. > > * Each release is smaller, so it's easier for downstream projects to > > adjust to each release -- instead of having this giant pile of changes > > to work through all at once every 6-12 months > > * End-users are less scared of updating, because the changes aren't so > > overwhelming, so they end up actually testing (and getting to take > > advantage of) the new stuff more. > > * We get feedback more quickly, so we can fix up whatever we break > > while we still know what we did. > > * And for larger changes, if we release them incrementally, we can get > > feedback before we've gone miles down the wrong path. > > * Releases come out on time more often -- sort of paradoxical, but > > with small, frequent releases, beta cycles go smoother, and it's > > easier to say "don't worry, I'll get it ready for next time", or > > "right, that patch was less done than we thought, let's take it out > > for now" (also this is much easier if we don't have another years > > worth of changes committed on top of the patch!). > > * If your schedule does slip, then you still end up with a <6 month > > release cycle. > > > > 1.6.x was branched from master in March 2011 and released in May 2011. > > 1.7.x was branched from master in July 2012 and still isn't out. But > > at least we've finally found and fixed the second to last bug! > > > > Wouldn't it be nice to have a 2-4 week beta cycle that only found > > trivial and expected problems? We *already* have 6 months worth of > > feature work in master that won't be in the *next* release. > > > > Note 1: if we do do this, then we'll also want to rethink the > > deprecation cycle a bit -- right now we've sort of vaguely been saying > > "well, we'll deprecate it in release n and take it out in n+1. > > Whenever that is". 3 months definitely isn't long enough for a > > deprecation period, so if we do do this then we'll want to deprecate > > things for multiple releases before actually removing them. Details to > > be determined. > > > > Note 2: in this kind of release schedule, you definitely don't want to > > say "here are the features that will be in the next release!", because > > then you end up slipping and sliding all over the place. Instead you > > say "here are some things that I want to work on next, and we'll see > > which release they end up in". Since we're already following the rule > > that nothing goes into master until it's done and tested and ready for > > release anyway, this doesn't really change much. > > > > Thoughts? > > Hey, my time to have a time-machine: > http://mail.scipy.org/pipermail/numpy-discussion/2008-May/033754.html > > I still think it is a good idea :) > > cheers, > David > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > http://mail.scipy.org/mailman/listinfo/numpy-discussion >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
