Hi Nemo, first, sorry for missing your message, I remember noticing it, postponing the response, then I forgot about it.
On Mon, Dec 20, 2021 at 12:06:28AM +0530, Nemo wrote: > Reaching out on behalf of endoflife.date[0], I wasn't aware of this project, this can indeed be quite useful for various distros or project that rely on external dependencies! > where we had a recent PR > for adding Haproxy[1]. haproxy does a really good job overall on this > front. For eg, I really appreciate how well documented the cycles are > (especially the "Hide/Show unmaintained" button). Thanks, happy that some find it useful :-) > The one challenge we're facing is with respect to EoL dates, which we > prefer to be absolute and complete[2]. Since haproxy EoL dates are > YYYY-Qn, it is hard for know in advance when a specific branch goes EoL. > > We're currently being conservative and using "start of quarter" as the > dates, but that leads to inaccuracies like 1.7 being marked as EoL[3] > when it is not. > > Is there any way for users to find out exact EoL dates in advance, or is > there an accepted answer for what Q1/Q2/Q3/Q4 would usually mean here? EOL dates are never precisely decided upfront, they're general guidance and are agreed upon with users. For example, 1.9 was supposed to die early in 2020-Q2 (possibly as early as April) and the last release was finally emitted on 31-July. Same goes for 1.6 which received updates till end of March 2020 despite being considered dead since end of previous year. And this state is intentional. The first purpose is to progressively increase the pressure on users who are really late without dropping them in the void. I prefer that someone asks "please could we have one more version in this branch for the time it takes us to upgrade" rather than knowing they're forced to run with a vulnerable one! The second reason is to not encourage users to deploy one last version that's possibly wrong on the day it's emitted, and to feel relieved because "surely it's rock solid now". That's a bad promise. If we emit a version it usually means we agree to fix it in case we broke it, hence the common message basically saying "no further release SHOULD be expected in that branch". Also software doesn't live only from updates but from support from the community and developers. What's the point of upgrading to a version if the day it's emitted it's considered EOL and everyone refuses to respond to questions about it on the grounds that it's EOL ? That doesn't stand. And who am I to tell the community "please do not respond to questions about 1.6 since it's dead" ? Some of them might be perfectly valid, and relevant to newer branches, but having such indications is useful for anyone to say "you should really upgrade now, your version is EOL or about to reach EOL". I know that some users would like to have an exact date so that they can feel like they're covered till the last day. And that's exactly what I want to avoid. Think about a consultant deploying the version the day before EOL. He might even be covered by a contract for doing this! Or the customer might insist that he does it. Here it's easier to say "no". As such, the EOL statement has to be read this way: with the end of life expected to happen within the announced period, we're free to stop working on it during that period and you should not expect to see any update nor receive help during nor after that period if nobody explicitly asks. And it turns out that it works extremely well, encouraging smooth upgrades, and users not feeling guilty to ask about unmaintained setups "just in case". Thus if you absolutely need to use a complete date, better be conservative so that users are not surprised, and consider that the last support day is the last day preceding the EOL period. This will match the minimum we'll do (useful for distros), and that will not prevent us from continuing to emit one or two versions past that date if needed to help some users in trouble, but it will remain a good warning that it's becoming risky to count on that possible margin. > For already-EoL releases, providing complete dates should be easier I guess? We could indeed adjust the entries to reflect the date of when it was last announced that the version was dead as we did in the past (only 1.6, 1.9 and 2.1 weren't updated like this). I don't think it brings much benefit though. And as you can see there's already the date of the last release in that branch anyway. Thanks, Willy
