• Release containers that are based on the current stable fedora ( would be f27 currently)
• Release containers that are based on the next stable fedora release (beta) ( would be f28 currently) with the idea to have these available for testing.

+1

This process would exclude rebuilding the f26

I think if we stop rebuilding those we should probably not leave them as available in the registry ORR we move them to some other name like /eol/ or something.

and rawhide based containers.

+1, although I could see some people might want this.

I :thumbsup: @dustymabe's comments as well.

I think if we stop rebuilding those we should probably not leave them as available in the registry >ORR we move them to some other name like /eol/ or something.

So the idea would be to move the container based on old fedora release to another namespace something like registry.fp.o/eol/f25/nginx

That looks right to me. However, I think dropping images which are no longer being updated makes sense. I don't think many, if any, people would update registry locations to continue using an image which won't be updated or supported by the community. I think it would add more work to those owning the registry. However, it won't hurt anything from the consumers point of view.

+1

I think this makes a lot of sense and follows along with the intent of the Atomic WG to "move forward more rapidly" just as is done with Atomic Host rpm-ostree releases. Historically this was different and the idea what to allow each "Fedora Generational Core" (FGC) to maintain their own version of each env and stack which was to be shipped by the original concept of modularity. The original Modularity Concept effectively said that we could have multiple FGCs available to support parallel installable versions of each Env/Stack and the container releases was going to be one of the release and distribution methods of these modules. That is why things are modeled the way they are today. However, effectively all of that has evolved over time and it makes a lot of sense to pivot to more forward looking approach and I think this is a solid plan.

My (unfinalized) plans for Flatpaks are:

• The application creator creates a stream corresponding to each different user-visible flatpak artifact that they want to expose - probably just a 'stable' and a 'unstable' (devel?) stream.
• The module configuration defines what Fedora versioned runtime (F28, F29, whatever) that each stream will build from. A maintainer could, if they wanted, have both the stable and unstable artifact target the same Fedora release and differ only in the application code.
• All the flatpaks for an application are in the same repository, and are tagged as 'latest-<streamname>'. latest-stable is also tagged as 'latest'.

If you have a server side container that is clearly an application - and not something that someone is going to be extensively building-on in a derived Dockerfile - I could see the same scheme making sense. This could even be done for non-modular containers - have stable/unstable branches in dist-git/containers and let the FROM line define the base image - but it makes much less sense, because if you are just pulling packages from the base Fedora package set, the F28 packages have to be stable, and anything unstable needs to be in rawhide, so keeping a Fedora-versioned branching scheme and automatically mapping to stable/unstable may make more sense.

Closing this ticket. I ll open new tickets for the actual changes to be implemented.