[new-product] add podman

[afbjorklund]

The git author date from the release tag in podman.git was used, most packages are still in "testing" repository.

Upstream does not package the server, only the client, so the distributions are supposed to build from source...

Page intentionally follows the docker-engine.md, but the product does identifiy itself as "Podman Engine":

core@localhost:~$ podman --remote version
Client:       Podman Engine
Version:      5.1.2
API Version:  5.1.2
Go Version:   go1.22.5
Built:        Wed Jul 10 02:00:00 2024
OS/Arch:      linux/arm64

Server:       Podman Engine
Version:      5.1.2
API Version:  5.1.2
Go Version:   go1.22.5
Built:        Wed Jul 10 02:00:00 2024
OS/Arch:      linux/arm64

Closes #3057

[welcome]

Thank you for opening this pull request 👍. If you are not familiar with the project, please check out our Contributing Guidelines and our Guiding Principles. Also take a look at our Hacking Guide if you intend to work on site internals.

[marcwrobel]

Thanks for this contribution @afbjorklund.

I am not sure about the way to decide whether a release is EOL. Asked for feedback of the endoflife.date team.

[afbjorklund]

Request for support policy:

containers/podman#23352

[afbjorklund]

I am not sure if there is a generic policy on source-only* products or versions with backports, in endoflife.date?

* As described in the discussion, the later (5.x) versions do include a custom OS with a custom server build.

The support times for the distributions are already available, and all the package versions are on repology.org

That is: Podman is supported in RHEL, but it is not the same version of Podman during the distribution lifetime...

[marcwrobel]

I am not sure if there is a generic policy on source-only* products or versions with backports, in endoflife.date?

No, if it's not clear we try to explain it in the description. And usually we don't mention the support provided for different builds in each distribution, where additional security patches can be added.

• As described in the discussion, the later (5.x) versions do include a custom OS with a custom server build.

The support times for the distributions are already available, and all the package versions are on repology.org

That is: Podman is supported in RHEL, but it is not the same version of Podman during the distribution lifetime...

We could start by saying that only the latest release is supported, as said in containers/podman#23352 (comment). We could even mention there is no documented release, support and EOL policy.

We can then explain that Podman is packages in many distributions and, as such, it may receive additional fixes outside of https://github.com/containers/podman/.

WDYT ?

[marcwrobel]

Have dates is usually more useful for users. If only the latest release is supported the following rule can be applied: eol(x) = releaseDate(x+1). WDYT ?

[afbjorklund]

Some releases are overlapping, so that probably needs some kind of statement from upstream

[afbjorklund]

WDYT ?

Probably ask during meeting, Aug 6.

https://podman.io/community

[marcwrobel]

Probably ask during meeting, Aug 6.

Hi @afbjorklund, did you have a response ?

[afbjorklund]

did you have a response ?

sure, they seemed to agree with the current PR - only the latest is "supported", the other are fedora or rhel specific

the meeting was recorded, but I don't think there was any major objection to what was currently being presented?

https://www.youtube.com/watch?v=q_OTd4zyN40&t=720s

[afbjorklund]

I don't have any updates on when the upstream podman.io website will be updated, that happens very rarely it seems.

https://github.com/containers/podman.io/issues

[marcwrobel]

Thanks @afbjorklund, sorry for the time it took me to reply.

Quickly listened to part of the meeting recording and indeed we can go ahead with what is currently documented.

Some minor improvement can be done:

• We could switch to github releases date if you think that's more accurate than git tags.
• When possible it's preferable to have dates for the eol field. We could use a rule such as eol(x) = max(releaseDate(x+1), latestReleaseDate(x)) to have those dates ?
• It should be clearer IMO to add a warning note stating that distributions offering Podman may support releases a bit longer than upstream.

Do you think those improvements are OK ? If they are, should we update this PR or implement them in a follow up PR ?

[afbjorklund]

• We could switch to github releases date if you think that's more accurate than git tags.

The dates were updated, it should now use the same dates as the automation will do later.

It should be clearer IMO to add a warning note stating that distributions offering Podman may support releases a bit longer than upstream.

I was hoping the project to come up with some updated information on https://podman.io

But otherwise I don't know, any such "support" would need to come from the Podman team.

I am not planning to do any more PR updates myself, but feel free to make it better in a later PR.

[marcwrobel]

Ok, so let's ignore my comments for now, merge this and improve later.

Thanks a lot for this contribution !

[welcome]

Thank you and congratulations for your first contribution! endoflife.date is a community wiki, and we're always looking for more contributions 🥇 💯 🎉.

[afbjorklund]

I was thinking the automation should update it from 5.2.0 to 5.2.2, but maybe it only runs daily and not before merge?

EDIT: Seems it missed the update train by 20 minutes: https://github.com/endoflife-date/endoflife.date/pull/5887/files

[marcwrobel]

Yes, latest releases are updated once a day.