Add first stable release when possible

[MeMineToMe]

Hi,
First of all, thanks a lot for the work already done, I found this project very useful for my needs !
Here is a suggestion : don't you think it would be helpful to identify the first stable release in a cycle ?
For example, let's have a look at MariaDB 10.6 cycle : 10.6.0 & 10.6.1 releases are Beta, 10.6.2 is a RC.
Only 10.6.3 and newer can be used in production.
What's your opinion ?
Regards

[hebbet]

Hi,
i am not totally sure what you are trying to say, but the first Version of MariaDB 10.6 added to the list was 10.6.3

95b5c35#diff-b306f5f09e367da343569d5a41a7f14ba87dd05a26b37451e107f3d03e0f47bfR49-R53

[MeMineToMe]

Actually, I'm using EOL information to analyse a platform, trying to identify if all software components are up-to-date.
So, for MariaDB for example, with current data available in your repo, I know that cycle 10.6 is ok, that EOL will be reached in 4 years but I can't tell, if 10.6.2 is installed for example, that this specific release is ok or not (it's not in that case). I just know that I'm not using the latest release available.
On the other hand, if 10.6.3 is installed, I'm also not able to say if this release is ok or not (it is in that case).

If in https://endoflife.date/api/mariadb.json, I had something like :

{
  "cycle": "10.6",
  "release": "2021-07-06",
  "eol": "2026-07-06",
  "firstStable": "10.6.3",
  "latest": "10.6.4",
  "latestShortHand": "1064"
}
...

I would be able to identify that my software needs to be updated or not.

[captn3m0]

All the product pages have a suggestion at the bottom:

You should be running one of the supported release numbers listed above in the rightmost column.

Which suggests that you ought to only be running one of 10.6.4, 10.5.12, ... as of today. The MariaDB project only guarantees fixes as long as you are running the latest patch release.

If you discover 10.6.1 running in your infrastructure, you should validate it, and come to the same conclusion - You need to upgrade to 10.6.4 irrespective of what the first stable release in the cycle was.

It becomes a concern if the endoflife.date/mariadb page ever suggested any of the RC releases in the 10.6.x timeline as current, and the validation would be incorrect - but we do take care to only work on stable releases (or mark beta releases separately if needed).

[MeMineToMe]

Thanks for your reply.
I understand your point of view and the way you decided to implement cycles/releases in endoflife project.
I don't fully agree because you know that in practice, very few self hosted services are able to update all their software components each time a new release is available. For my previous example, I'd like to be able to raise a simple warning if running MariaDB 10.6.3 (because you may not be affected by bugs fixed in 10.6.4 and decide to wait for a future release that fixes only security vulnerabilities for example) while a critical error must be raised if running lower versions.
Anyway, thanks for your time and again, bravo for the work done !

[captn3m0]

I totally agree - it's a hard problem to upgrade everything everywhere.

But this project exists so you know which version you should be upgrading to and when. It's up to the end users to decide if they wanna set an alert or warning or alarm bells on version mismatch.

Thanks for the feedback 👍🏼. I'll keep an eye out for MariaDB per-stable releases.

[captn3m0]

While this information isn't currently exposed, we are now tracking first stable releases of many projects, including mariadb and mysql.

You can get this via JSON at https://github.com/endoflife-date/release-data/blob/main/releases/mariadb.json, https://github.com/endoflife-date/release-data/blob/main/releases/mysql.json

But we plan to expose this in the API.