Re: Subversion 1.10.0 end-of-life
Nathan Hartman wrote on Thu, Apr 28, 2022 at 15:25:55 -0400: > if we start releasing more frequent LTS .0 versions, we would end up > promising to support too many lines simultaneously. I hadn't > considered that because I was working from the assumption that we > aren't releasing new lines frequently enough for that to be a problem, > but we'd better document that in HACKING so the dev community doesn't > forget that in the future and create that situation. Maybe it'll be an > explanation about when to call a release LTS vs Regular. E.g., if > there exist two supported release lines then any further releases > should be Regular until the older LTS drops out. While there, HACKING should tell the RM to record the "Is it LTS or regular?" decision into release-lines.yaml:lts_release_lines.
Re: Subversion 1.10.0 end-of-life
Nathan Hartman wrote on Thu, Apr 28, 2022 at 15:25:55 -0400: > the explanation about support periods should be easy to understand. Index: staging/roadmap.html === --- staging/roadmap.html(revision 1900368) +++ staging/roadmap.html(working copy) @@ -86,41 +86,46 @@ title="Link to this section"> -Subversion plans to make a regular release every 6 months, - with a Long-Term Support (LTS) release every 2 years. - Regular releases are intended to deliver new features more quickly, while - LTS releases are intended to provide stability over longer periods. +Subversion has two types of releases: + regular releases are intended to deliver new features more quickly, while + LTS releases are intended to provide stability over longer periods. - - -type of release -emphasis -release every -support period -release numbers - - -LTS release -stability -2 years -4 years -1.10, 1.14, ... - - -regular release -features -6 months -6 months -1.11, 1.12, 1.13, ... - - +The two types releases differ in their support lifetime: + + +Regular releases are supported for six months from the date of +their initial release. For instance, 1.11.x was supported until six months +after the announcement of 1.11.0. + +LTS releases are supported for four years from the date of their +initial release. For instance, 1.15.x will supported until four years after +the announcement of 1.15.0. + +LTS releases are supported until three months after the release of +the the next LTS. + +The previous two guarantees cumulate: for an LTS release line to be declared +end-of-life (EOL), it has to both have been first released over four +years before and have been supported in parallel to a newer LTS +release line for at least three months. + +For instance, assume 1.42.0 is released on 2042-07-01 and 1.42 is declared +an LTS line. In this case, 1.42 will be supported at least until 2046-06-30 +(with no ifs, buts, or maybes). Furthermore, it is expected that a newer LTS +release (1.43.0, 1.44.0, etc.) will be made before 2046-04-01, leaving three +months for upgrading installations. In case no newer LTS release is made +until, say, 2048-01-01, the lifetime of 1.42 will automatically be extended +until 2048-03-31. + +At any given time there will be at least one supported LTS release. + + + During the support period, we commit to providing updates that fix high priority issues such as security and data loss or corruption. We may also -sometimes fix other issues as appropriate to the emphasis of each release. -If a release takes longer than planned, we will extend the support periods -of the previous releases accordingly. +sometimes fix other issues as appropriate to the emphasis of each release. In this context, "release" means an increment of the minor release number, which is the middle number in our three-component system. @@ -131,6 +136,9 @@ bugfixes have accumulated to warrant it. Major new releases, such as Subversion 2.0, will probably be done much like the minor releases, just with more planning around the exact features. + +To date, every release since 1.0 has been LTS, with the exception of 1.11, +1.12, and 1.13 which were regular. For more information about Subversion's release numbering and compatibility policies, see the section entitled
Re: Subversion 1.10.0 end-of-life
On Thu, Apr 28, 2022 at 3:25 PM Nathan Hartman wrote: > better document that in HACKING so the dev community doesn't forget that > in the future and create that situation. Maybe it'll be an explanation > about when to call a release LTS vs Regular. E.g., if there exist two > supported release lines then any further releases should be Regular until > the older LTS drops out. > Um, that was supposed to read: "E.g., if there exist two supported *LTS* release lines then any further releases should be Regular until the older LTS drops out." Cheers, Nathan
Re: Subversion 1.10.0 end-of-life
On Thu, Apr 28, 2022 at 3:12 PM Stefan Sperling wrote: > On Thu, Apr 28, 2022 at 01:29:43PM +, Daniel Shahaf wrote: > > Stefan Sperling wrote on Thu, 28 Apr 2022 09:55 +00:00: > > > I think it would be better to have such details spelled out in English > > > in a manner that is easy to understand for anyone, with illustrating > > > examples, instead of (or in addition to) mathematical notation that > > > requires abstract thinking to figure out. > > > > I'm unable to interpret this charitably. > > Fine, I'll best just shut up then. > Please, let's not have any of that!! You made a perfectly valid point that if we start releasing more frequent LTS .0 versions, we would end up promising to support too many lines simultaneously. I hadn't considered that because I was working from the assumption that we aren't releasing new lines frequently enough for that to be a problem, but we'd better document that in HACKING so the dev community doesn't forget that in the future and create that situation. Maybe it'll be an explanation about when to call a release LTS vs Regular. E.g., if there exist two supported release lines then any further releases should be Regular until the older LTS drops out. Also it's a valid point that the explanation about support periods should be easy to understand. Cheers, Nathan
Re: Subversion 1.10.0 end-of-life
On Thu, Apr 28, 2022 at 01:29:43PM +, Daniel Shahaf wrote: > Stefan Sperling wrote on Thu, 28 Apr 2022 09:55 +00:00: > > I think it would be better to have such details spelled out in English > > in a manner that is easy to understand for anyone, with illustrating > > examples, instead of (or in addition to) mathematical notation that > > requires abstract thinking to figure out. > > I'm unable to interpret this charitably. Fine, I'll best just shut up then.
Re: Subversion 1.10.0 end-of-life
Stefan Sperling wrote on Thu, 28 Apr 2022 09:55 +00:00: > I think it would be better to have such details spelled out in English > in a manner that is easy to understand for anyone, with illustrating > examples, instead of (or in addition to) mathematical notation that > requires abstract thinking to figure out. I'm unable to interpret this charitably. More below. > On Wed, Apr 27, 2022 at 11:43:02PM -0400, Nathan Hartman wrote: >> On Wed, Apr 27, 2022 at 4:56 PM Daniel Sahlberg >> wrote: >> > >> > Den ons 27 apr. 2022 kl 21:02 skrev Daniel Shahaf >> > : >> >> >> >> As to the general rule, I think we're missing a piece: the overlap >> >> period. We should say something along the lines of "Every LTS release >> >> will be supported for at least Y years, or until M months after the >> >> release of another LTS .0, whichever comes later.". >> > >> > >> > +1 to have an overlap period. >> > >> > Y = 4, M = 3? Or M = 6? >> >> I'm also +1 to have an overlap period, and the idea of "at least Y >> years, or until M months after the release of another LTS .0, >> whichever comes later" seems quite reasonable to me. > > Shouldn't this say "whichever comes earlier"? No. That would make Y meaningless: once 1.15.0 is release, admins won't be able to rely on any "Y years" promise since a 1.16.0 might be released sooner than M months before the Y years are up. That's basically the equivalent of telling someone "I'll babysit your kids on 2026-04-27 unless it's a sunny day". A promise with strings attached isn't. > Otherwise, the M months rule would never apply in case we release more > than one LTS line within Y years, right? Almost. It would never apply if we release two LTS .0's within $Y years - M months$ of each other. > Would we then end up fully supporting several lines of LTS releases? Yes. > Example with Y=4: > release 1.15.0 in year 1 (support 1.15) > release 1.16.0 in year 2 (support 1.15, 1.16) > release 1.17.0 in year 3 (support 1.15, 1.16, 1.17) > release 1.18.0 in year 4 (support 1.15, 1.16, 1.17, 1.18) > release 1.19.0 in year 5 (support 1.16, 1.17, 1.18, 1.19) > ... Books whose plots involve annual Apache Subversion releases go in the sci-fi section ;-) And if it becomes reality, we could make 1.16 a Regular release (as Nathan pointed out), or apply the "experimental" descriptor to new features more liberally. Daniel
Re: Subversion 1.10.0 end-of-life
On Wed, Apr 27, 2022 at 11:43:02PM -0400, Nathan Hartman wrote: > On Wed, Apr 27, 2022 at 4:56 PM Daniel Sahlberg > wrote: > > > > Den ons 27 apr. 2022 kl 21:02 skrev Daniel Shahaf : > >> > >> As to the general rule, I think we're missing a piece: the overlap > >> period. We should say something along the lines of "Every LTS release > >> will be supported for at least Y years, or until M months after the > >> release of another LTS .0, whichever comes later.". > > > > > > +1 to have an overlap period. > > > > Y = 4, M = 3? Or M = 6? > > > I'm also +1 to have an overlap period, and the idea of "at least Y > years, or until M months after the release of another LTS .0, > whichever comes later" seems quite reasonable to me. Shouldn't this say "whichever comes earlier"? Otherwise, the M months rule would never apply in case we release more than one LTS line within Y years, right? Would we then end up fully supporting several lines of LTS releases? Example with Y=4: release 1.15.0 in year 1 (support 1.15) release 1.16.0 in year 2 (support 1.15, 1.16) release 1.17.0 in year 3 (support 1.15, 1.16, 1.17) release 1.18.0 in year 4 (support 1.15, 1.16, 1.17, 1.18) release 1.19.0 in year 5 (support 1.16, 1.17, 1.18, 1.19) ... I think it would be better to have such details spelled out in English in a manner that is easy to understand for anyone, with illustrating examples, instead of (or in addition to) mathematical notation that requires abstract thinking to figure out.
