Opinion wanted: codata.find(sub) used to print a list of strings. A while ago, in response to http://projects.scipy.org/scipy/ticket/996, I changed it to return the list of strings. But this is an API change, and should follow the deprecation policy. One way to do this is to restore find() to its previous behavior, and deprecate the function. At the same time, add a new function, find_string(sub), which returns the list of strings. What do you think? Warren Warren Weckesser wrote:
David Cournapeau wrote:
On Sun, May 30, 2010 at 2:07 AM, Warren Weckesser <warren.weckesser@enthought.com> wrote:
David Cournapeau wrote:
On Sun, May 30, 2010 at 12:00 AM, Warren Weckesser <warren.weckesser@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
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev