Given the negative reaction to quick deprecation of LTS releases, I also now most prefer Loïc's proposal. It's semver with a little extra to help folks out.
I'd also most prefer seeing 1.9 being changed to 2.0 if this proposal were accepted, but that is not a strong opinion given that I am not familiar with the pain involved with renaming the deprecation warnings. Sent from my iPhone > On Jun 15, 2015, at 08:54, Loïc Bistuer <loic.bist...@gmail.com> wrote: > > 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. -- 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/16BE36DE-D44C-4ED0-AFF0-448C5CC8A514%40ryanhiebert.com. For more options, visit https://groups.google.com/d/optout.
