Nathan Hartman wrote on Tue, 26 Apr 2022 13:58 +00:00: > On Tue, Apr 26, 2022 at 5:57 AM Stefan Sperling <s...@elego.de> wrote: >> >> On Mon, Apr 25, 2022 at 10:05:58PM +0200, Daniel Sahlberg wrote: >> > Hi, >> > >> > According to the Roadmap, How we plan releases[1], 1.10.0 is a LTS release >> > that will receive support for 4 years. According to the News archive[2], >> > 1.10.0 was released 2018-04-13. >> > >> > 1.10.0 was released approximately two months before the transition to the >> > LTS support policy and I have not been able to dig out what was promised >> > previously. >> >> Before LTS releases, the 2 most recent lines of releases were supported. >> The most recent one would receive all types of bug fixes, the second one >> would receive security or data-corruption fixes only. ⋮ >> Going back to the old policy would mean that 1.10 would be supported >> until 1.15 comes out. At which point only 1.15 and 1.14 would be supported. > > > The older policy seems simpler. > > One good takeaway from the new policy is that we give the expected > lifespan of a release line to help admins plan server upgrades. It > also helps us with our own planning. [...] For reasons like this, declaring > the expected lifespan as we've been doing since the new policy is > helpful.
+1 > We could keep the LTS vs Regular distinction because it standardizes > on two possible lifespans, either 4 years or 6 months, BUT stop > promising to make Regular releases, neither at 6 months nor any other > frequency. It becomes optional to make a Regular release if and when > it makes sense and the developers and community are willing and able > make it happen. +1 > Back to Daniel's question: Since we aren't currently making a new LTS > release every 2 years, I think it makes sense to go with what Stefan > suggests, meaning EOL 1.10.x when 1.15.0 is released. > We actually already document (in https://subversion.apache.org/roadmap.html#release-planning, which is linked from the download page) that 1.9 and 1.10 will be LTS with the four-year lifetime. Assuming we wrote that part _before_ we released 1.10.0, that means 1.10 is EOL now and we can mark it as such. > At this time, we might warn that 1.10.x is "deprecated" (or something > along those lines) by which I mean to warn users that 1.10.x will be > EOL when the next minor release is made and encourage upgrading to > 1.14.x as soon as reasonable. This means we could still make 1.10.x > patch releases if it makes sense to do so, but admins should not > count on that support continuing for any definable length of time. > > I know that seems kind of ad-hoc. It would be very helpful if we could > as a community decide this policy question and then update the site. 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.". But the general principle of having only one supported LTS at this point in time, since 1.10 has EOL'd, seems sound to me. We have fewer hands on deck nowadays, so we should try to support fewer lines. Cheers, Daniel
