Evernow

> As far as I'm aware, 2.0.x is functionally dead. I don't think it's wise to continue using it, even if it's not been officially declared EOL. I believe 2.0.x...

> If that is correct, then practically, there is no LTS release. > > Based on the definition provided in that file, 2.1.5 would both be the _OpenZFS current_ AND...

Congrats on the progress!

Would this be resolved with https://github.com/endoflife-date/endoflife.date/pull/421 ? I don't think it's a good idea to have the ESM date as the end of security support for the reasons mentioned above.

Is there actually a difference in the support cycle depending on the code? I could see carriers supporting their carrier branded devices for shorter amounts, but to keep track of...

I prefer an approach where unsupported release is hidden and there is a checkbox at the top a user can uncheck to show. However this behavior should be able to...

> So +1 to adding ELS as a separate row for the supported releases. Is this currently possible?

> Yeah, just an extra repeated row with `ELS` in the `releaseCycle` field. Can you clarify? Would it be like this: ``` - releaseCycle: "RHEL 8" release: 2019-05-01 support: 2024-05-31...

Looking at further, I believe you meant having a completely different releaseCycle with ELS in the name? Personally believe that is not ideal. Just by looking at the Windows entry...

Is this covered with https://github.com/endoflife-date/endoflife.date/pull/1254 ?