On Wed, Mar 6, 2013 at 10:56 PM, Nathaniel Smith <[email protected]> wrote: > On Wed, Mar 6, 2013 at 10:53 PM, Robert Kern <[email protected]> wrote: >> On Wed, Mar 6, 2013 at 10:45 PM, Nathaniel Smith <[email protected]> wrote: >>> On Wed, Mar 6, 2013 at 10:33 PM, Robert Kern <[email protected]> wrote: >>>> On Wed, Mar 6, 2013 at 8:09 PM, Nathaniel Smith <[email protected]> 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 _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
