[Numpy-discussion] 1.8 release

David Cournapeau cournape@gmail....
Sun Jan 13 18:19:59 CST 2013

On Sun, Jan 13, 2013 at 5:26 PM, Nathaniel Smith <njs@pobox.com> wrote:
> On Sun, Jan 13, 2013 at 7:03 PM, Charles R Harris
> <charlesr.harris@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:

I still think it is a good idea :)


More information about the NumPy-Discussion mailing list