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/F36EA2A5-4D9F-489C-82B9-7AE4D93B258F%40ryanhiebert.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to