EOL for a single version

[deronnax]

trafficstars

Hello. Thanks for EOL. Would it be acceptable to have a behavior where we could specify one version of a package to get the eol for? I think of something like this:

$ eol [email protected]
┌──────────┬────────────┬─────────┬────────────────┬────────────┬────────────┬──────────────────────────────┐
│ cycle    │  release   │ latest  │ latest release │  support   │    eol     │   supportedPythonVersions    │
├──────────┼────────────┼─────────┼────────────────┼────────────┼────────────┼──────────────────────────────┤
│ 5.1      │ 2024-08-07 │ 5.1.6   │   2025-02-05   │ 2025-04-30 │ 2025-12-31 │ 3.10 - 3.13 (added in 5.1.3) │
└──────────┴────────────┴─────────┴────────────────┴────────────┴────────────┴──────────────────────────────┘

[hugovk]

Thanks for the suggestion, sounds like it could be useful.

Right now:

❯ eol django
┌──────────┬────────────┬─────────┬────────────────┬────────────┬────────────┬──────────────────────────────┐
│ cycle    │  release   │ latest  │ latest release │  support   │    eol     │   supportedPythonVersions    │
├──────────┼────────────┼─────────┼────────────────┼────────────┼────────────┼──────────────────────────────┤
│ 5.1      │ 2024-08-07 │ 5.1.6   │   2025-02-05   │ 2025-04-30 │ 2025-12-31 │ 3.10 - 3.13 (added in 5.1.3) │
│ 5.0      │ 2023-12-04 │ 5.0.12  │   2025-02-05   │ 2024-08-07 │ 2025-04-30 │         3.10 - 3.12          │
│ 4.2 LTS  │ 2023-04-03 │ 4.2.19  │   2025-02-05   │ 2023-12-04 │ 2026-04-30 │ 3.8 - 3.12 (added in 4.2.8)  │
│ 4.1      │ 2022-08-03 │ 4.1.13  │   2023-11-01   │ 2023-04-05 │ 2023-12-01 │ 3.8 - 3.11 (added in 4.1.3)  │
│ 4.0      │ 2021-12-07 │ 4.0.10  │   2023-02-14   │ 2022-08-03 │ 2023-04-01 │          3.8 - 3.10          │
│ 3.2 LTS  │ 2021-04-06 │ 3.2.25  │   2024-03-04   │ 2021-12-07 │ 2024-04-01 │ 3.6 - 3.10 (added in 3.2.9)  │
│ 3.1      │ 2020-08-04 │ 3.1.14  │   2021-12-07   │ 2021-04-06 │ 2021-12-07 │  3.6 - 3.9 (added in 3.1.3)  │
│ 3.0      │ 2019-12-02 │ 3.0.14  │   2021-04-06   │ 2020-08-03 │ 2021-04-06 │ 3.6 - 3.9 (added in 3.0.11)  │
│ 2.2 LTS  │ 2019-04-01 │ 2.2.28  │   2022-04-11   │ 2019-12-02 │ 2022-04-11 │ 3.5 - 3.9 (added in 2.2.17)  │
│ 2.1      │ 2018-08-01 │ 2.1.15  │   2019-12-02   │ 2019-04-01 │ 2019-12-02 │          3.5 - 3.7           │
│ 2.0      │ 2017-12-02 │ 2.0.13  │   2019-02-12   │ 2018-08-01 │ 2019-04-01 │          3.4 - 3.7           │
│ 1.11 LTS │ 2017-04-04 │ 1.11.29 │   2020-03-04   │ 2017-12-02 │ 2020-04-01 │ 2.7 - 3.7 (added in 1.11.17) │
└──────────┴────────────┴─────────┴────────────────┴────────────┴────────────┴──────────────────────────────┘

How would you get the EOL for 4.2 LTS?

Would it be useful to be able to eol django@lts and just see the LTS releases?

Let's pretend Django had both 5.10 and 5.1 releases. If it was a substring search, would it be okay to return both of those for eol [email protected]?

[deronnax]

hmmmm, I would follow the python main package manager convention, as Poetry and PDM, since - I think - the @ convention comes from their world - so what comes after the @ is a strict self-contained valid number-only version number. Hence:

How would you get the EOL for 4.2 LTS?

[email protected]. The fact that it is a LTS doesn't come into play for the @ notation.

Would it be useful to be able to eol django@lts and just see the LTS releases?

Then that would more likely be a flag, something like --only-lts. The correct term to use for the option name remains to be figured out.

Let's pretend Django had both 5.10 and 5.1 releases. If it was a substring search, would it be okay to return both of those for eol [email protected]?

Then, no. It's a numeric matching, not a string matching, no substring match then. Then [email protected] is django 5.1, that's it.

[adriens]

Then that would more likely be a flag, something like --only-lts

➕ 1‍⃣ for this, it would be very useful 🙌

[hugovk]

hmmmm, I would follow the python main package manager convention, as Poetry and PDM, since - I think - the @ convention comes from their world - so what comes after the @ is a strict self-contained valid number-only version number. Hence:

How would you get the EOL for 4.2 LTS?

[email protected]. The fact that it is a LTS doesn't come into play for the @ notation.

👍

Is there a spec for the @ notation?

Would it be useful to be able to eol django@lts and just see the LTS releases?

Then that would more likely be a flag, something like --only-lts. The correct term to use for the option name remains to be figured out.

👍

We do put together "4.2 LTS" from two fields, so that sounds okay.

Let's pretend Django had both 5.10 and 5.1 releases. If it was a substring search, would it be okay to return both of those for eol [email protected]?

Then, no. It's a numeric matching, not a string matching, no substring match then. Then [email protected] is django 5.1, that's it.

No substring match, that seems okay.

One concern: there's over 350 products on endoflife.date, not all "versions" are numbers and dots. For example, apple-watch has series-10, aws-lambda has nodejs12.x, freebsd has releng/12.1, surface has Surface Laptop (1st gen), windows has 10-21h2-w, and so on.

So full string matching? How would you ask for something with a space?