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

[Warren Weckesser]

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.

Warren



> Next time I'll write out the months, dd/mm vs mm/dd is obviously not 
> so clear.
>
> If you are still in a cleaning mood, in io there is a lot of stuff you 
> are allowed to remove. The 0.7.0 release notes say:
>
> Several functions in ``scipy.io <http://scipy.io>`` have been 
> deprecated and will be
> removed in the 0.8.0 release including ``npfile``, ``save``, ``load``,
> ``create_module``, ``create_shelf``, ``objload``, ``objsave``,
> ``fopen``, ``read_array``, ``write_array``, ``fread``, ``fwrite``,
> ``bswap``, ``packbits``, ``unpackbits``, and ``convert_objectarray``.
> Some of these functions have been replaced by NumPy's raw reading and
> writing capabilities, memory-mapping capabilities, or array methods.
> Others have been moved from SciPy to NumPy, since basic array reading
> and writing capability is now handled by NumPy.
>
> Cheers,
> Ralf
> ------------------------------------------------------------------------
>
> _______________________________________________
> SciPy-Dev mailing list
> SciPy-Dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-dev
>