I don't have a strong opinion either way on semver, but I think it's a bit
reference to "RemovedInDjango19Warning". Do you have any thoughts on that?
with the cutover to Python 3.
Post by Loïc BistuerMAJOR version when you make incompatible API changes,
MINOR version when you add functionality in a backwards-compatible manner, and
PATCH version when you make backwards-compatible bug fixes.
We are only breaking the first rule with backwards incompatible changes
that don't undergo deprecations, but considering that we do our very best
to avoid these, I think it's fair enough to just document it as a caveat.
SemVer makes it easier to see at a glance how long you are supposed to
support Django versions as a 3rd-party app author and where you can rely on
shims. It also brings more visibility to our efforts to ease straddle two
LTS versions (supporting shims from LTS+1 for 1 additional release). I
think it's enough to justify adopting it even if we aren't "pure" in its
implementation.
--
Loïc
Post by Tim GrahamI'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).
Post by Tim GrahamI think Collin's proposal can match semver without additional overhead
when LTS are the final minor releases of any given major branch.
Post by Tim Graham1.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.
Post by Tim GrahamFeatures 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".
Post by Tim Graham--
Loïc
Post by Tim GrahamI'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
Post by Tim GrahamPost by Tim GrahamAn alternative would be for the LTS to be the second-to-last minor
release before a major version bump.
Post by Tim GrahamPost by Tim GrahamI'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.
Post by Tim GrahamPost by Tim Graham2.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.
Post by Tim GrahamPost by Tim GrahamI'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.
Post by Tim GrahamPost by Tim GrahamIf 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
Post by Tim GrahamPost by Tim Graham2.2 - 0 mos - (LTS) No features dropped
3.0 - 8 mos - All deprecations, including the LTS deprecations, are
removed
Post by Tim GrahamPost by Tim Graham3.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
Post by Tim GrahamPost by Tim Graham4.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.
Post by Tim GrahamPost by Tim GrahamRyan
--
You received this message because you are subscribed to the Google
Groups "Django developers (Contributions to Django itself)" group.
Post by Tim GrahamPost by Tim GrahamTo unsubscribe from this group and stop receiving emails from it, send
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.
Post by Tim GrahamPost by Tim GrahamFor 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.
Post by Tim GrahamTo unsubscribe from this group and stop receiving emails from it, send
<javascript:>.
Post by Tim GrahamVisit 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.
Post by Tim GrahamFor more options, visit https://groups.google.com/d/optout.