+1

+1

+1

Users should first upgrade to Podman 5.8 first (will be release on all active Fedora releases) and reboot before upgrading to Podman 6 to ensure migration.

Would be great if this specifically was also mentioned in the Release Notes (though updating to the most recent packages before doing a system-upgrade is already documented, it's not a hard-coded requirement).

but +1

I would like to request an podman 6 release exception for this change. Please let me know if you would like me to create a new ticket.

As we are actively working on podman 6, we cant make the Beta Freeze or Beta release deadline for podman 6 final as there are lot of breaking changes that we are planning address in podman 6. But we are working hard to get a final podman 6 release before Final Freeze which is 2026-03-31.

Please let us know if you have questions on this regard.

Thank you.

It depends on how late you intend to be. Are we talking a couple days? A week? Or are you missing the entire beta period?

If you can't make it at all during the beta period, we should probably defer this Change, because the risk of breaking everyone unintentionally is too high.

Alternately, will there be a Podman 6 Beta or similar release that we CAN ship in Fedora 44 Beta?

@ngompa @sgallagh We will create RC's before the podman 6 final but we dont know whether we can get a RC during the beta period.

@mohanboddu I don't think we necessarily need a full-on RC, but we need to be able to assess the level of breakage that comes from a major upgrade. If there's a point where the major new features look ready, but the polish isn't there, can you put that in F44 in time for Beta?

If the answer to that is "no", then I think we will need to defer the Change to F45. We might be able to possibly ship it as an alternative podman6 package if it can live alongside Podman 5, but the "default" container manager would not change.

@sgallagh We can try to get something in for Beta (most probably will need a beta freeze exception as it might not be ready by beta freeze) but it could not be fully ready especially not all breaking changes will be addressed, is that okay?

@sgallagh We can try to get something in for Beta (most probably will need a beta freeze exception as it might not be ready by beta freeze) but it could not be fully ready especially not all breaking changes will be addressed, is that okay?

The phrase "not all breaking changes will be addressed" makes me anxious. Do you mean that the breakages won't have landed at all by that point? If so, I think we really need to be talking about deferral here. The point of the Beta is to let users test what we expect to ship. If we are going to continue introducting incompatible changes after that, what is the point of Beta at all?

Well, there a lot of breaking changes in podman 6 which are explained in the change request (detailed version is available here) of which we are very confident that we can address all the breaking changes by beta release except for one.

This particular one should be ready by final freeze.

That's quite a tight deadline. I'm beginning to think that F44 might be too early for this to land?

Changing to -1 to prevent acceptance and trigger meeting.

@ngompa Is this going to be discussed this week(today's meeting) or can it wait until next week? Some of the engineering team is still on PTO and would appreciate if it can be discussed in next week's meeting. Sorry for the trouble.

It's on the agenda for today's meeting: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/DKRKCSX5JQAYAH4QIM27IO3DFTFLSOKM/#DKRKCSX5JQAYAH4QIM27IO3DFTFLSOKM

We can move discussion of this topic to next week, if that helps.

Thanks @decathorpe I would really appreciate it if it can be moved to next week. Thats helps us alot.

Discussion of this topic was postponed to next week's meeting (log starting at ~18:51 UTC).

Well, there a lot of breaking changes in podman 6 which are explained in the change request (detailed version is available here) of which we are very confident that we can address all the breaking changes by beta release except for one.

The problem is that one change is seems to be the one most likely to cause problems to users. And many people already start upgrading after Beta is released, so fundamentally changing the configuration format in a way that requires manual intervention is something that should not be done after Beta. Also, there clearly are many moving parts that'll most likely require some polishing and debugging before they are ready to be widely used. Also, podman and the tools that build on it are an important part of the Fedora offering. I don't think we should push fundamental changes after Beta. Overall, I think it's better to delay by one release then to push barely tested code so late.

+1 to the Change for now. But if it turns out that an rc1 is not available after Beta, I think we must discuss delaying to F45.

This issue will be discussed at the next meeting on 2026-01-20

AGREED: (+7, 0, -0) Podman 6 is approved to land in Fedora 44
with the following conditions:

1. The complete set of incompatible changes must be in updates-testing by the beginning of the Beta Freeze.
2. Upgrades must be cleanly supported from Fedora 42.

Announced in https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/IXPVJMEORBD34ZVW3C43WTUK6NR3SC6H/

Just FYI, we are pushing podman 6 to Fedora 45

This Change has been deferred from F45 to F46.

Note: The milestone on this issue reflects when FESCo originally reviewed this Change and is preserved as historical record.

Looks like this was now unintentionally deferred twice (once to F45, and then again to F46)?

The previous comment about deferral to F46 was made in error. This Change should remain targeted for Fedora Linux 45.

@decathorpe I have a script to defer the changes, where I add the changes to process to a json file which the python script reads. It turns out that the solution never distinguished between "pending" and "processed" -- meaning that if proposals remained in the json file for my own historical reference, they would be picked up again when the script was run. I thought this was an isolated incident and I had misprocessed this change before, but after a deeper review, I found the root cause and updated to code to add a "processed" flag. All changes that were deferred one release further than they should have been have been rectified.

Thank you for bringing it to my attention.