I'm -0 (borderline -1) on that proposal. I don't think we should compromise on our historical commitment of deprecating over 2 releases, especially since it's aligned with the policy of Python itself and much of the ecosystem.
It should be as easy as possible for 3rd-party apps to straddle 2 LTS releases, but when it comes to user projects we should make it as easy as possible to keep up with the latest stable. Sticking to LTS versions deprive you from up to three years of innovation in Django, IMO it's only appropriate for projects in maintenance mode. Our current policy allows you to take advantage of new features right away while having almost a year and a half to deal with deprecations. The only additional overhead of my counterproposal is an extra 8 months of support for features deprecated in an LTS for a total of 16 months. Considering non-LTS releases require between 16 months and 24 months I think it's very manageable. Regarding timeline for adoption, I prefer switching right away but I'm also happy with a 2.1 > 3.0 switch, so whatever is more popular. Also it shouldn't get lost because regardless of the SemVer decision we'll need to update RemovedInDjango21Warning in master. > On Jun 15, 2015, at 19:37, Josh Smeaton <josh.smea...@gmail.com> wrote: > > I really like Ryan's second proposal (quoting here again): > > 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 > > It'll mean that the maximum time a feature can be supported while deprecating > is 2 years. The shortest it can be supported is a single release if the > deprecation is made in an LTS - which I think is fine because the LTS is > supported for 3 years anyway. It perfectly adheres to semver (which is a nice > property, but not the be-all and end-all), and still allows libraries to > straddle two LTS releases. Is there a good reason we couldn't use this model? > > And I agree with Tim that changing the version numbers of already planned > releases is not a good idea. The version naming can wait until the current > Removed* warnings are gone - and timing it with the Python 3 only release > sounds like a fairly good motivation to bump the major version and continue > with semver from there. Provided we remember/document the plan :) > > On Sunday, 14 June 2015 09:58:41 UTC+10, Tim Graham wrote: > Of course RemovedInDjango19Warning is also in 1.7 and a lot of docs reference > Django 1.9. I'm not enthusiastic about updating all that. > > On Sunday, June 14, 2015 at 1:43:50 AM UTC+2, Loïc Bistuer wrote: > > > On Jun 13, 2015, at 20:43, Tim Graham <timog...@gmail.com> wrote: > > > > I don't have a strong opinion either way on semver, but I think it's a bit > > late to rebrand 1.9 as 2.0 considering we've release code and docs with > > reference to "RemovedInDjango19Warning". Do you have any thoughts on that? > > We could plan the change for after the next LTS (2.1 -> 3.0) to correspond > > with the cutover to Python 3. > > > Currently we have: > > 1.8: > RemovedInDjango19Warning(DeprecationWarning) - Deprecations from 1.7 > RemovedInDjango20Warning(PendingDeprecationWarning) - Deprecations from > 1.8 > > master: > RemovedInDjango20Warning(DeprecationWarning) - Deprecations from 1.8 > RemovedInDjango21Warning(PendingDeprecationWarning) - Deprecations from > master > > In any case, implementing the new policy will require updating warnings from > master: RemovedInDjango21Warning needs to become either > RemovedInDjango22Warning or RemovedInDjango31Warning with the switch to > SemVer. > > The question is whether it's too invasive to update warnings in a 1.8 patch > release. If we ensure that RemovedInDjango19Warning remains importable by > aliasing it to RemovedInDjango20Warning(DeprecationWarning), I think it's > compatible enough not to delay implementing the scheme by another two years, > especially considering how warnings are normally used. But if we want to be > super cautious we could just leave the code as it is and document the problem > in the 1.8 release notes, after all we are extending the lifespan of the > shims (at least in appearance) which isn't as problematic as if we were > shortening it. > > -- > Loïc > > > -- > 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/4c636d6d-4365-48dc-932a-5a67cec44a51%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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/8FD2862C-D50D-44B9-8517-8C37417BF8BB%40gmail.com. For more options, visit https://groups.google.com/d/optout.
