I'm still in favor of "Collin's proposal." You'll need to convince me that keeping deprecations around longer is worth having somewhat meaningful version numbers, but I'm not sure I really consider dropping deprecation shims as "incompatible API changes" that justify a major version bump. For example, if I run on 2.X (whatever is right before the version where features are dropped) without deprecation warnings, then upgrading to 3.0 isn't any more difficult than other upgrades. It might be a nice touch to call the version after the next LTS (2.1 under Collin's proposal) "3.0" since it will drop Python 2 support, but it's not really important IMO
On Friday, June 12, 2015 at 8:00:30 PM UTC-4, Ryan Hiebert wrote: > > An alternative would be for the LTS to be the second-to-last minor release > before a major version bump. > > I'm also ignoring the transition for the sake of hypotheticals. I'm also > assuming that 2.2 is the last release of the 2.X series. > > 2.1 - 0 mos - (LTS) No features dropped > 2.2 - 8 mos - No features dropped > 3.0 - 16 mos - Drop all features deprecated by 2.1 > 3.1 - 24 mos - (LTS) No features dropped > 3.2 - 32 mos - No features dropped > 4.0 - 40 mos - Drop all features deprecated by 3.1 > 4.1 - 48 mos - (LTS) No features dropped > > It would mean that features deprecated before an LTS cannot be dropped > until two versions after the LTS, but it fits semver pretty well, and > doesn't speed up our deprecation removal. > > I'd argue for a major version dropping _all_ deprecated features. This has > the downside of speeding up our removal process in the last version of a > major release, and it encourages people to stay longer on the release > previous, since they won't have as much opportunity to fix them. It would > also mean that features deprecated in the last minor version of a major > version line would need to skip the pending deprecation warnings. > > If it were acceptable to do that, then I'd argue for the LTS to be the > _last_ in a major version line, rather than the second-to-last. That would > probably be my overall preferred, though I do recognize the previously > mentioned drawbacks. Anything deprecated in an LTS in that case would skip > the pending deprecation warning, and go straight to the deprecation > warning. The deprecation timeline would then look like this: > > 2.2 - 0 mos - (LTS) No features dropped > 3.0 - 8 mos - All deprecations, including the LTS deprecations, are > removed > 3.1 - 16 mos - No features dropped > 3.2 - 24 mos - (LTS) No features dropped > 4.0 - 32 mos - All deprecations, including the LTS deprecations, are > removed > 4.1 - 40 mos - No features dropped > 4.2 - 48 mos - (LTS) No features dropped > > > I think those are probably the two best LTS support release schedules that > follow semver. > > Ryan -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/f887421b-c470-491f-b5f0-a12af397bfe1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
