I'm happy to give it a try if there's consensus that it might help. On the other hand, this doesn't account for the inevitable backwards incompatible changes that come along. For example, someone in the survey said "Django 1.7 is a hard change for clients and it should have been 2.0 so that they realize what the jump means." Unfortunately, it's impossible to anticipate when features like that might come along and I'm not sure we'd want to delay features so that they don't first appear in an LTS release (at least, this would be a pretty big change in Django development and slow down innovation in my view).
On Saturday, June 13, 2015 at 6:25:44 AM UTC-4, Loïc Bistuer wrote: > > I think Collin's proposal can match semver without additional overhead > when LTS are the final minor releases of any given major branch. > > 1.8 LTS > 2.0 (Drop features from 1.7) > 2.1 (Drop features from 1.8 LTS) > 2.2 LTS > 3.0 (Drop features from 2.0, 2.1) > 3.1 (Drop features from 2.2 LTS) > 3.2 LTS > > That way we can say that features are never removed until the next major > release. > > Features deprecated in a LTS leak onto x.1 releases but that's fine (1 > release deprecations are a no-go IMO), we can document it as "deprecations > from a major branch will be either loud or gone in the following major > branch". > > -- > Loïc > > > On Jun 13, 2015, at 04:16, Tim Graham <timog...@gmail.com <javascript:>> > wrote: > > > > 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-develop...@googlegroups.com <javascript:>. > > To post to this group, send email to django-d...@googlegroups.com > <javascript:>. > > 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. > > -- 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/fc7744d0-20ed-43f0-8cfa-860494b32a0c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
