On Mon, May 31, 2010 at 6:26 PM, Warren Weckesser < warren.weckesser@enthought.com> wrote:
Ralf Gommers wrote:
On Tue, Jun 1, 2010 at 1:21 AM, Warren Weckesser <warren.weckesser@enthought.com <mailto:warren.weckesser@enthought.com>> wrote:
David Cournapeau wrote: > On Sun, May 30, 2010 at 2:07 AM, Warren Weckesser > <warren.weckesser@enthought.com <mailto:warren.weckesser@enthought.com>> wrote: > >> David Cournapeau wrote: >> >>> On Sun, May 30, 2010 at 12:00 AM, Warren Weckesser >>> <warren.weckesser@enthought.com <mailto: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.
The revised schedule said June 3.
Argh, so it did, and still does. OK, I'll still try to get the changes done by the June 3 beta.
Well, it agrees with the documentation. It's just that I vaguely recall returning the absolute error in the original. I suppose an error method could be added. Oh, and I believe someone updated the constants so they are more recent than 2002, 2005 IIRC, so that should be changed in the documentation. <snip> Chuck