Different lifecycle phases

[lfrancke]

Just having a single "end" date doesn't seem sufficient to me.

We'd need different lifecycle phases. One example is here: https://access.redhat.com/support/policy/updates/openshift#ocp4_phases

[captn3m0]

We have discussed this in our prior efforts at endoflife.date, and came to same conclusion. "Support" is a broad term, and it means different things to different projects.

Our current effort at the releases.json specification (WIP PR: https://github.com/endoflife-date/releases.json/pull/1) uses generic "plans" (https://github.com/endoflife-date/releases.json/pull/1/files#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R117-R134), with their own attributes for eol, releaseDate, latestVersion, but it isn't clear enough.

Another effort by @noqcks (https://github.com/endoflife-date/endoflife.date/discussions/3484) uses a vendor decided integer value (support.level.int) to differentiate between various support levels. This has the issue with the levels not necessarily always remaining in sorted order, since support levels can change for a product over time. But overall, this documents phases much better.

In my experience, attempting to use a single lifecycle terminology does not work across multiple projects. It is much better to provide clear attributes for what is covered under each phase. The important attributes to cover are:

• security: Whether or not security fixes are provided
• features: Whether or not new features are available.
• commercial: Whether this lifecyle phase is available via an additional commercial contract (compared to procurement).
• availability: Whether this phase includes availability of the product. For eg, old devices are discontinued (you can not buy them), but are covered under support. We've documented this for Raspberry Pi, Intel and other software in the past.

As long as there are clear identifiers for each phase, tooling can be built to accommodate for that.