[SciPy-Dev] Mea culpa: deprecation and API changes

[David Cournapeau]

On Sun, May 30, 2010 at 2:07 AM, Warren Weckesser
<warren.weckesser at enthought.com> wrote:
> David Cournapeau wrote:
>> On Sun, May 30, 2010 at 12:00 AM, Warren Weckesser
>> <warren.weckesser at enthought.com> wrote:
>>
>>
>>
>>> What I would like to do is leave trunk as it is, and after 0.8 is
>>> branched, make the appropriate changes in the branch to follow the
>>> deprecation policy.  Is that a reasonable approach?
>>>
>>
>> May I ask why do you want to do that way ?
>
> Because it doesn't look like I will have time to make the changes before
> Ralf branches 0.8 tomorrow.
>
>>  Putting the deprecation in
>> the release branch means people tracking trunk will never see them.
>>
>
> Good point.    But in case I am misinterpreting what you mean by
> "tracking trunk" and "see":  I assume this means it is important to have
> a record of the deprecation changes in the svn logs, and not that some
> who is *using* scipy from trunk also needs to be exposed to the
> deprecation warning for some minimum amount of time.

actually, I meant both. For example, I often use scipy from trunk, and
rarely from releases.  I will never see the deprecation, which is not
good.

Also, I think we should generally try to never put things in release
branches, but always backport from trunk (except for branch specific
changes). Having the 0.8 branch created tomorrow does not mean you
cannot put the changes into trunk, and backport them in 0.8 later -
deprecation which were already agreed on are the kind of things which
can happen after the branching without putting much burden on the
release process.

> If the changes are
> made to trunk, then they will be undone immediately after 0.8 is
> branched.

deprecated features do not be to be removed just after the trunk is
opened for the next release cycle (0.9 here).

> ever have a copy that includes the deprecation warnings.  In other
> words, deprecations are linked to releases, not to "time in trunk".

Indeed - but I think that we should let the deprecation be in place
for as long as possible in the source code repository.

cheers,

David