Den ons 27 apr. 2022 kl 21:02 skrev Daniel Shahaf <d...@daniel.shahaf.name>:
> 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 > I'm also +1 on declaring an expected life span. > 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 > Also +1. At the current release pace we should try to make every release an LTS, but if we would make releases more often in the future then we could declare some of them "Regular". > > > 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. > That part was written two months after 1.10 was released according to the log of roadmap.html. > 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. > If we decide that we should give 1.10 an extended life, I agree it should be "deprecated" and we should only backport things that are really REQUIRED (security and data corruption issues). > > > > 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.". > +1 to have an overlap period. Y = 4, M = 3? Or M = 6? But maybe we can be even stricter with only fixing security and data corruption issues during M. 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. > /Daniel [1] https://subversion.apache.org/roadmap.html#release-planning
