On Mon, Jan 14, 2013 at 1:19 AM, 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 :) > +1 for faster and time-based releases. 3 months does sound a little too short to me (5 or 6 would be better), since a release cycle typically doesn't fit in one month. Ralf
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion