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 >> <daniel.l.sahlb...@gmail.com> wrote: >> > >> > Den ons 27 apr. 2022 kl 21:02 skrev Daniel Shahaf >> > <d...@daniel.shahaf.name>: >> >> >> >> 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
