Hi Matt, On 06/11/2015 07:30 PM, Matt Austin wrote: > On 11 June 2015 at 01:37, Collin Anderson <cmawebs...@gmail.com> wrote: >> >> I'd propose something slightly different, that's very close to our current >> deprecation timeline: >> 1.8 (LTS): No features dropped. >> 1.9: Dropped features deprecated in 1.5, 1.6, 1.7 >> 2.0: Dropped features deprecated in 1.8 >> 2.1 (LTS): No features dropped. >> 2.2: Dropped features deprecated in 1.9, 2.0 >> 2.3: Dropped features deprecated in 2.1 >> >> Seems to me features deprecated in an LTS are fair game to disappear in the >> next LTS. This allows us to remove "dotted paths in reverse() and url()" >> because that's deprecated in 1.8. >> >> If we can guarantee compatibility between LTSs, I think that would be a huge >> win, at the cost of extending the removal of some deprecated features by one >> release (8 months). >> > > Hi everyone, > > Sorry to stick my nose in, but thought I might throw a potential > spanner-in-the works with this release discussion, in regard to > version naming. > > I understand that the current version system doesn't have too much > inherent meaning, and that 2.0 will come after 1.9 'just so we don't > stay on 1.x forever'. > > With a more structured release plan, and LTS releases, would it be > worth considering LTS releases as 'major' version numbers, with > regular releases and 'minor' version releases? It would be easier to > identify LTS releases at a glance, and might provide more meaning to > the versioning scheme?
I find this idea tempting too, but (as Collin indirectly pointed out) the problem is that it flips semver on its head, which some people might find surprising. Because in Collin's schedule it's the _LTS_ releases where no APIs will be removed, whereas any non-LTS release might have APIs removed. Donald proposed in IRC that we could go with a standard major/minor/bugfix semver approach, with the added guarantee that every removed feature will be deprecated in one major release first (to preserve the ability to straddle two major releases, or upgrade major->major without hitting removed APIs). This is nice and simple and conforms to semver, but it means that deprecated features would hang around quite a bit longer. Just for the sake of comparison and devils advocate, here's what a full switch to semver could look like for Django (I'll hand-wave past the transition and just start with a hypothetical 2.0 release, which is major/"LTS"): 2.0 - 0 mos - "LTS" 2.1 - 8 mos - may add/deprecate features, but not remove 2.2 - 16 mos - may add/deprecate features, but not remove 3.0 - 24 mos - "LTS" - remove any features already deprecated in 2.0 3.1 - 32 mos - may add/deprecate features, but not remove 3.2 - 40 mos - may add/deprecate features, but not remove 4.0 - 48 mos - "LTS" - removes features deprecated in 2.1, 2.2, or 3.0 ... etc ... Just like in the current proposal, 2.0 would continue to receive 2.0.X security releases until a year after 3.0 is released (thus for three years, given no delays). 2.1 would receive bugfix releases until 2.2 is released, and thereafter security releases until 3.0 is released. 2.2 would receive security releases until 3.1 is released. (This is just like the current system.) This scheme conforms to semver, and allows for no-breakage straddling/upgrades from major(LTS) to major(LTS) release. The cost, compared to the current proposal, is that a deprecated feature might need to stick around _in master_ for almost four years (if it's deprecated in e.g. 2.1 and then finally removed in 4.0). Whereas in Collin's proposal, the longest a deprecated feature would ever stay in master is about two years (e.g. from 1.9 to 2.1 in his schedule above). I'll admit that the simplicity (and semantic version numbering) of this scheme does grow on me, but I don't get the feeling that the core team is really ready to accept that length of continued support for deprecated APIs. Carl -- 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/557B0FA6.1010605%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
