[Numpy-discussion] 1.7.1

[Nathaniel Smith]

On Tue, Feb 26, 2013 at 9:21 PM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
>
>
> On Tue, Feb 26, 2013 at 2:03 PM, Ralf Gommers <ralf.gommers at gmail.com>
> wrote:
>>
>>
>>
>>
>> On Tue, Feb 26, 2013 at 7:47 PM, Charles R Harris
>> <charlesr.harris at gmail.com> wrote:
>>>
>>> When should we put out 1.7.1? Discuss ;)
>>
>>
>> When we have X times more fixes in maintenance/1.7.x than the one commit
>> with a one-liner fix that we have now. Where X is >= 5 at least, unless
>> there's a very high prio fix that needs releasing asap?

There is, actually; we (probably I) broke
np.diagonal()/ndarray.diagonal() so any array that has diagonal()
called on it gets pinned in memory forever. That's why the
scikits-learn folk are grumpy.

>> Having at least 2 months between bugfix releases unless something very
>> urgent comes up would also make sense to me.

I'm not sure why -- bug-fixes don't age like wine or anything.
Obviously there's a trade-off around how much effort we want to spend
on managing releases versus other things, but I don't see why there'd
be anything *wrong* with putting out a tiny point-release whenever we
find a real bug in a stable series. No-one has to upgrade...

>> I think we do need to be diligent in backporting fixes quickly after
>> they're merged into master, and not leaving that till right before the
>> release candidate is scheduled.
>
> Ralph, the backports are PR's marked with the backport tag and there are
> more than one. It is up to Ondrej to decide whether to include them or not.

Oh argh, we should probably document some of this stuff, I just merged
a bunch of them myself (which all looked fine of course). Mea culpa.

For the moment: Ondrej, heads up that I did this!

For the future: I definitely see the benefit of having one person
keeping track of what goes in and what doesn't as we get into the late
stage of the release cycle, but in between, maybe it makes sense for
us all to work together on keeping the basic backports branch up to
date and taking some of the load off the release manager? (I'll try
not to continue implementing this plan unless we agree on it,
though...)

-n