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

[Charles R Harris]

On Mon, May 31, 2010 at 6:26 PM, Warren Weckesser <
warren.weckesser at enthought.com> wrote:

> Ralf Gommers wrote:
> >
> >
> > On Tue, Jun 1, 2010 at 1:21 AM, Warren Weckesser
> > <warren.weckesser at enthought.com
> > <mailto:warren.weckesser at enthought.com>> wrote:
> >
> >     David Cournapeau wrote:
> >     > On Sun, May 30, 2010 at 2:07 AM, Warren Weckesser
> >     > <warren.weckesser at enthought.com
> >     <mailto: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
> >     <mailto: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.
> >
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20100531/9af0dfd5/attachment.html>