[Numpy-discussion] Numpy deprecation schedule

[Robert Kern]

On Wed, Mar 6, 2013 at 10:56 PM, Nathaniel Smith <njs at pobox.com> wrote:
> On Wed, Mar 6, 2013 at 10:53 PM, Robert Kern <robert.kern at gmail.com> wrote:
>> On Wed, Mar 6, 2013 at 10:45 PM, Nathaniel Smith <njs at pobox.com> wrote:
>>> On Wed, Mar 6, 2013 at 10:33 PM, Robert Kern <robert.kern at gmail.com> wrote:
>>>> On Wed, Mar 6, 2013 at 8:09 PM, Nathaniel Smith <njs at 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