[Numpy-discussion] 1.8 release

[Frédéric Bastien]

Hi,

I don't volontear for the next release manager, but +1 for shorter
releases. I heard just good comments from that. Also, I'm not sure it
would ask more from the release manager. Do someone have an idea? The
most work I do as a release manager for theano is the
preparation/tests/release notes and this depend on the amont of new
stuff. And this seam exponential on the number of new changes in the
release, not linear (no data, just an impression...). Making smaller
release make this easier.

But yes, this mean more announces. But this isn't what take the most
times. Also, doing the release notes more frequently mean it is more
recent in memory when you check the PR merged, so it make it easier to
do.

But what prevent us from making shorter release? Oother priorities
that can't wait, like work for papers to submit, or for collaboration
with partners.

just my 2cents.

Fred

On Mon, Jan 14, 2013 at 7:18 AM, Matthew Brett <matthew.brett at gmail.com> wrote:
> Hi,
>
> On Mon, Jan 14, 2013 at 12:19 AM, David Cournapeau <cournape at gmail.com> wrote:
>> On Sun, Jan 13, 2013 at 5:26 PM, Nathaniel Smith <njs at pobox.com> wrote:
>>> On Sun, Jan 13, 2013 at 7:03 PM, Charles R Harris
>>> <charlesr.harris at 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 :)
>
> I guess it is the release manager who has by far the largest say in
> this.  Who will that be for the next year or so?
>
> Best,
>
> Matthew
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion