Support for podman releases and EOL

[afbjorklund]

I created a PR for the endoflife.date project:

• [new-product] add podman endoflife-date/endoflife.date#5505

Based on a user request for a podman page:

• [Request - Product] podman endoflife-date/endoflife.date#3057

---

The Docker page looks like:

https://endoflife.date/docker-engine

The Podman page looks like:

https://deploy-preview-5505--endoflife-date.netlify.app/podman

---

Ideally, the endoflife.date project would llike podman.io to supply both the release timeline and the support policy:

https://endoflife.date/recommendations

Currently the dates are just taken from github releases, and the supported cycles are taken from the Fedora packages:

https://github.com/containers/podman/releases
https://packages.fedoraproject.org/pkgs/podman/podman/

[Luap99]

I am totally in favor of creating a page where this is listed on documented.
As you know we cannot really give dates as we only support the latest release and the releases are not at a fixed interval.

In general the question is what does "supported" mean, just security updates? Using the fedora baseline is likely the most realistic for that.

But as an upstream maintainer I still ask anyone who files issues here to try to reproduce on the latest version even if there are older version in fedora and we will not create new 4.9 release for "normal" bug fixes unless someone can convince us that it is really critical.

And IMO I would really just call it Podman not Podman Engine.

[afbjorklund]

Should also mention that the packages for different distributions is already listed here:

https://repology.org/project/podman

[Luap99]

I mean in terms of security issues we only fix the latest version purely upstream speaking.

Yes there is the special case with fedora 39 and podman 4.9 right now but that is not a general rule I would say. So if the goal is to have some form of automation over there then it should really on list the latest IMO.

Of course if we create a document then we could list such cases properly and you could pull from that which I think would be the easiest thing.

[afbjorklund]

As far as I know, the automation just bumps the latest patch version within each "release" :

(https://github.com/endoflife-date/endoflife.date/commits/master/products/docker-engine.md)

    latest: "5.1.2"
    latestReleaseDate: 2024-07-10

    latest: "5.0.3"
    latestReleaseDate: 2024-05-10

So new cycles are still added manually, with a release date - currently matching the .0 patch:

(For docker-engine.md they are using https://github.com/moby/moby/milestones for this)

-   releaseCycle: "5.1"
    releaseDate: 2024-05-29
    eol: false

-   releaseCycle: "5.0"
    releaseDate: 2024-03-19
    eol: true

[afbjorklund]

Now it shows all releases (except the latest), as EOL. There is no special tracking of packaging in Fedora releases.

[afbjorklund]

Renamed from podman-engine to podman, and added the 5.2 and the 3.x release cycles to the version matrix.

[afbjorklund]

The timeline I created gives an indication of the average lifetime of a minor release:

endoflife-date/endoflife.date#3057 (comment)

As you say, it varies a little between the releases - but on average it is rather similar:

I filed a bug about the missing 5.0.0 release blog.

• Release blog is not updated for version 4.4.0 and up podman.io#316

The GitHub release notes vary a lot, in scope and in length.

Main EOL question is about 3.4 and 4.9, what date they stop?

[Luap99]

blog posts moved to https://blog.podman.io/

https://blog.podman.io/2024/03/podman-5-0-has-been-released/

[afbjorklund]

Unfortunately that breaks the links for the "pattern", like the other URL issues with the new podman.io website

Anyway, there were some notes about it (changelog and image) in the https://endoflife.date/recommendations

[afbjorklund]

Seems like the main issue was missing redirects, and missing tagging of posts with the "releases" category.

https://blog.podman.io/category/releases/