[Numpy-discussion] 1.8 release
Sun Jan 13 17:26:43 CST 2013
On Sun, Jan 13, 2013 at 7:03 PM, Charles R Harris
> 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
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
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.
More information about the NumPy-Discussion