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

[Warren Weckesser]

David Cournapeau wrote:
> 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.
>
>   


OK.  It might be a couple more days before I can make the reversions and 
deprecations, but I'll get them in before the beta release on June 6.

Warren