[Numpy-discussion] Going toward time-based release ?

[Jarrod Millman]

On Sun, May 11, 2008 at 11:31 PM, Robert Kern <robert.kern at gmail.com> wrote:
> That's not what I'm referring to. Before 1.0 was released, people were
> worried about the stability of the API, and Travis said that 1.0.x
> would maintain API compatibility, but that 1.1, "maybe a year from
> now," would be the opportunity to make API changes again. I think that
> statement colored development substantially. We had to add features to
> 1.0.x releases instead of just bugfixes because 1.1 was going to be
> this big thing.

Ah...  I see.

>>> I would very much like to get away from
>>> that and follow Python's model of only doing bugfixes/doc-enhancements
>>> in micro releases, new features in minor releases and code breakage
>>> never (or if we absolutely must, only after one full minor release
>>> with a deprecation warning).
>>
>> +1
>> I absolutely agree.

To clarify, in particular, I was agreeing that if we absolutely must
break code we should only do it after a full minor release with a
deprecation warning.  I don't want a repeat of what happened with MA.

> You keep saying that you agree with me, but then you keep talking
> about allowing "minor code breakage" which I do not agree with. I
> don't think I am communicating the aversion to code breakage that I am
> trying to espouse. While strictly speaking, there is a conceivable
> reading of the words you use ("I think that it is reasonable to allow
> some API breakage in a minor release" for example) which I can agree
> with, I think we're meaning slightly different things. In particular,
> I think we're disagreeing on a meta level. I do agree that
> occasionally we will be presented with times when breaking an API is
> warranted. As a prediction of future, factual events, we see eye to
> eye.

Are you saying that the changes to histogram and median should require
waiting until 2.0--several years from now?  When I say that we may
allow minor API breakage this is the kind of thing I mean.  I think
that both instances are very reasonable and clean up minor warts.  I
also think that in both cases the implementation plan is reasonable.
They first provide the new functionality as an option in a new minor
release, then in the subsequent release switch the new functionality
to the default but leave the old behavior accessable.

The MA situation was handled slightly differently, which is
unfortunate.  I think that it is a reasonable change to make in a
minor release, but we should have provided a warning first.  At least,
we are providing the old code still.  Do you think that we should
revisit this issue?  Since we are importing the new MA from a
different location maybe we should move the old code back to it's
original location.  Would it be reasonable to have:
from numpy import ma  -->  new code
from numpy.core import ma  --> old code w/ a deprecation warning

Thanks,

-- 
Jarrod Millman
Computational Infrastructure for Research Labs
10 Giannini Hall, UC Berkeley
phone: 510.643.4014
http://cirl.berkeley.edu/