[Numpy-discussion] Numpy deprecation schedule
Wed Mar 6 16:56:37 CST 2013
On Wed, Mar 6, 2013 at 10:53 PM, Robert Kern <firstname.lastname@example.org> wrote:
> On Wed, Mar 6, 2013 at 10:45 PM, Nathaniel Smith <email@example.com> wrote:
>> On Wed, Mar 6, 2013 at 10:33 PM, Robert Kern <firstname.lastname@example.org> wrote:
>>> On Wed, Mar 6, 2013 at 8:09 PM, Nathaniel Smith <email@example.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.:
>>>> 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...
More information about the NumPy-Discussion