Numpy deprecation schedule
A number of items on the 1.8 todo list are reminders to remove things that we deprecated in 1.7, and said we would remove in 1.8, e.g.: https://github.com/numpy/numpy/issues/596 https://github.com/numpy/numpy/issues/294 But, since 1.8 is so soon after 1.7, we probably shouldn't actually do that. I suggest we switch to a time-based deprecation schedule, where instead of saying "this will be removed in N releases" we say "this will be removed in the first release on or after (now+N months)". I also suggest that we set N=12, because it's a round number, it roughly matches numpy's historical release cycle, and because AFAICT that's the number that python itself uses for core and stdlib deprecations. Thoughts? -n
That sound good. To be sure, the "now" mean the first release that include the deprecation, in that case NumPy 1.7? Fred On Wed, Mar 6, 2013 at 3:09 PM, Nathaniel Smith <njs@pobox.com> wrote:
A number of items on the 1.8 todo list are reminders to remove things that we deprecated in 1.7, and said we would remove in 1.8, e.g.: https://github.com/numpy/numpy/issues/596 https://github.com/numpy/numpy/issues/294
But, since 1.8 is so soon after 1.7, we probably shouldn't actually do that.
I suggest we switch to a time-based deprecation schedule, where instead of saying "this will be removed in N releases" we say "this will be removed in the first release on or after (now+N months)".
I also suggest that we set N=12, because it's a round number, it roughly matches numpy's historical release cycle, and because AFAICT that's the number that python itself uses for core and stdlib deprecations.
Thoughts? -n _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Wed, Mar 6, 2013 at 9:38 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Wed, Mar 6, 2013 at 8:21 PM, Frédéric Bastien <nouiz@nouiz.org> wrote:
That sound good. To be sure, the "now" mean the first release that include the deprecation, in that case NumPy 1.7?
Yes.
+1 $ git add HOWTO_DEPRECATE.rst.txt ? Ralf
On Wed, Mar 6, 2013 at 9:24 PM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Wed, Mar 6, 2013 at 9:38 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Wed, Mar 6, 2013 at 8:21 PM, Frédéric Bastien <nouiz@nouiz.org> wrote:
That sound good. To be sure, the "now" mean the first release that include the deprecation, in that case NumPy 1.7?
Yes.
+1
$ git add HOWTO_DEPRECATE.rst.txt ?
+1 I'm vaguely intimidated by the doc structure, so I'm not sure where this would go, but... aside from a formal description of how one does a deprecation and the difference between DeprecationWarning and FutureWarning, etc., we might even want to just add a whole page in the manual that just lists the current status of all ongoing deprecations, the releases where each change was made, the date for the next change, etc., and use that as our canonical reference that we check before each release? Since this is information that end-users want to be able to see? ("I got this weird warning... what is it trying to tell me? Which release started issuing it? What's my deadline for fixing this?") And because this whole cycle of filing multiple bugs and then shunting them off to the next release is pretty awkward. -n
On Wed, Mar 6, 2013 at 8:09 PM, Nathaniel Smith <njs@pobox.com> wrote:
A number of items on the 1.8 todo list are reminders to remove things that we deprecated in 1.7, and said we would remove in 1.8, e.g.: https://github.com/numpy/numpy/issues/596 https://github.com/numpy/numpy/issues/294
But, since 1.8 is so soon after 1.7, we probably shouldn't actually do that.
I suggest we switch to a time-based deprecation schedule, where instead of saying "this will be removed in N releases" we say "this will be removed in the first release on or after (now+N months)".
We can always delay removal if a particular release comes sooner than originally expected. The deprecation policy is just that we specify minimum version numbers at which the features can be removed. It's not really a firm schedule. I do take your suggestion to heart, though. We shouldn't remove stuff faster than 12 months or so. I just think that it should modify our release process, not our "marking for deprecation" process. -- Robert Kern
On Wed, Mar 6, 2013 at 10:33 PM, Robert Kern <robert.kern@gmail.com> wrote:
On Wed, Mar 6, 2013 at 8:09 PM, Nathaniel Smith <njs@pobox.com> wrote:
A number of items on the 1.8 todo list are reminders to remove things that we deprecated in 1.7, and said we would remove in 1.8, e.g.: https://github.com/numpy/numpy/issues/596 https://github.com/numpy/numpy/issues/294
But, since 1.8 is so soon after 1.7, we probably shouldn't actually do that.
I suggest we switch to a time-based deprecation schedule, where instead of saying "this will be removed in N releases" we say "this will be removed in the first release on or after (now+N months)".
We can always delay removal if a particular release comes sooner than originally expected. The deprecation policy is just that we specify minimum version numbers at which the features can be removed. It's not really a firm schedule.
I do take your suggestion to heart, though. We shouldn't remove stuff faster than 12 months or so. I just think that it should modify our release process, not our "marking for deprecation" process.
I'm not sure what this means in practical terms, though? Take the stuff deprecated in 1.7, released 2013-02-10. From here it seems plausible that the first release after 2014-02-10 could be 1.9, 1.10, or even, if we end up really embracing the small-quick-release cycle, 1.11. So which should we write down as our expected version number for the 1.7 deprecations? -n
On Wed, Mar 6, 2013 at 10:45 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Wed, Mar 6, 2013 at 10:33 PM, Robert Kern <robert.kern@gmail.com> wrote:
On Wed, Mar 6, 2013 at 8:09 PM, Nathaniel Smith <njs@pobox.com> wrote:
A number of items on the 1.8 todo list are reminders to remove things that we deprecated in 1.7, and said we would remove in 1.8, e.g.: https://github.com/numpy/numpy/issues/596 https://github.com/numpy/numpy/issues/294
But, since 1.8 is so soon after 1.7, we probably shouldn't actually do that.
I suggest we switch to a time-based deprecation schedule, where instead of saying "this will be removed in N releases" we say "this will be removed in the first release on or after (now+N months)".
We can always delay removal if a particular release comes sooner than originally expected. The deprecation policy is just that we specify minimum version numbers at which the features can be removed. It's not really a firm schedule.
I do take your suggestion to heart, though. We shouldn't remove stuff faster than 12 months or so. I just think that it should modify our release process, not our "marking for deprecation" process.
I'm not sure what this means in practical terms, though? Take the stuff deprecated in 1.7, released 2013-02-10. From here it seems plausible that the first release after 2014-02-10 could be 1.9, 1.10, or even, if we end up really embracing the small-quick-release cycle, 1.11. So which should we write down as our expected version number for the 1.7 deprecations?
If. I would leave the policy alone until we consistently implement such a release cycle that makes it regularly problematic. -- Robert Kern
On Wed, Mar 6, 2013 at 10:53 PM, Robert Kern <robert.kern@gmail.com> wrote:
On Wed, Mar 6, 2013 at 10:45 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Wed, Mar 6, 2013 at 10:33 PM, Robert Kern <robert.kern@gmail.com> wrote:
On Wed, Mar 6, 2013 at 8:09 PM, Nathaniel Smith <njs@pobox.com> wrote:
A number of items on the 1.8 todo list are reminders to remove things that we deprecated in 1.7, and said we would remove in 1.8, e.g.: https://github.com/numpy/numpy/issues/596 https://github.com/numpy/numpy/issues/294
But, since 1.8 is so soon after 1.7, we probably shouldn't actually do that.
I suggest we switch to a time-based deprecation schedule, where instead of saying "this will be removed in N releases" we say "this will be removed in the first release on or after (now+N months)".
We can always delay removal if a particular release comes sooner than originally expected. The deprecation policy is just that we specify minimum version numbers at which the features can be removed. It's not really a firm schedule.
I do take your suggestion to heart, though. We shouldn't remove stuff faster than 12 months or so. I just think that it should modify our release process, not our "marking for deprecation" process.
I'm not sure what this means in practical terms, though? Take the stuff deprecated in 1.7, released 2013-02-10. From here it seems plausible that the first release after 2014-02-10 could be 1.9, 1.10, or even, if we end up really embracing the small-quick-release cycle, 1.11. So which should we write down as our expected version number for the 1.7 deprecations?
If. I would leave the policy alone until we consistently implement such a release cycle that makes it regularly problematic.
It's being problematic right now, we need some process in place to handle these bugs through the 1.8 release and to make sure we don't drop them on the floor later... -n
On Wed, Mar 6, 2013 at 10:56 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Wed, Mar 6, 2013 at 10:53 PM, Robert Kern <robert.kern@gmail.com> wrote:
On Wed, Mar 6, 2013 at 10:45 PM, Nathaniel Smith <njs@pobox.com> wrote:
On Wed, Mar 6, 2013 at 10:33 PM, Robert Kern <robert.kern@gmail.com> wrote:
On Wed, Mar 6, 2013 at 8:09 PM, Nathaniel Smith <njs@pobox.com> wrote:
A number of items on the 1.8 todo list are reminders to remove things that we deprecated in 1.7, and said we would remove in 1.8, e.g.: https://github.com/numpy/numpy/issues/596 https://github.com/numpy/numpy/issues/294
But, since 1.8 is so soon after 1.7, we probably shouldn't actually do that.
I suggest we switch to a time-based deprecation schedule, where instead of saying "this will be removed in N releases" we say "this will be removed in the first release on or after (now+N months)".
We can always delay removal if a particular release comes sooner than originally expected. The deprecation policy is just that we specify minimum version numbers at which the features can be removed. It's not really a firm schedule.
I do take your suggestion to heart, though. We shouldn't remove stuff faster than 12 months or so. I just think that it should modify our release process, not our "marking for deprecation" process.
I'm not sure what this means in practical terms, though? Take the stuff deprecated in 1.7, released 2013-02-10. From here it seems plausible that the first release after 2014-02-10 could be 1.9, 1.10, or even, if we end up really embracing the small-quick-release cycle, 1.11. So which should we write down as our expected version number for the 1.7 deprecations?
If. I would leave the policy alone until we consistently implement such a release cycle that makes it regularly problematic.
It's being problematic right now,
Changing existing process is like automation: don't do it until the problem bites you twice. That's why I suggested that we don't change things until it's *regularly* problematic.
we need some process in place to handle these bugs through the 1.8 release and to make sure we don't drop them on the floor later...
Bump the milestones to 1.9. -- Robert Kern
participants (4)
-
Frédéric Bastien -
Nathaniel Smith -
Ralf Gommers -
Robert Kern