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.
