So now when we have EPEL 10.0 and EPEL 10.1, is there a supported way to build for 10.0 and tag into both? Aka build once, ship everywhere.
In RHEL, this is called “branch inheritance,” but I would keep the branches in sync here.
I was thinking of building in Koji once, but created 2 bodhi updates (except that is not possible nowadays, is it?). I guess I can create the EPEL 10.0 update, and when it reaches stable, ask relengs to tag it to EPEL 10.1 as well, but that involves bothering other humans, so it does not scale. Also, no gating/CI/etc. would happen then.
This is currently the only method we have to do this. We use this workflow for the epel-release package for example because we need to have a single NVR for the epel-release-latest-10.noarch.rpm symlink that is used in the setup instructions. The general expectation is that maintainers will either only build in the leading branch (deferring the change for RHEL users until the next minor version) or create two separate builds and updates.
Consider the same question on the Fedora side. Is there a way to build for f41 and then tag the build into f42 and f43? Yes, but it involves manual releng intervention and should be considered an exception workflow, not a standard one. It’s the same situation for EPEL.
If we were to try to make this a standard workflow (no releng intervention), I believe this is how it would need to happen. I think to accomplish it we would need to change koji permissions to allow maintainers to add additional *-testing-candidate tags to their builds, e.g. an epel10.0 build would get epel10.0-testing-candidate by default, and maintainers could manually add epel10.1-testing-candidate as well. In theory that should allow the same build to be used in two updates, but there are probably code paths in bodhi that would need to be updated to handle this as well. Perhaps bodhi could even allow the creation of both updates from the same submission form (assuming all the builds in the form have the necessary candidate tags).
I’m not necessarily opposed to this, but I’m not really convinced that it’s worth the effort.
Relevant note: On Flock, somebody said something like “every new Fedora version is completely different, but the minor EL releases will always be almost identical”. This is something to consider when comparing the situation with Fedora.
ELS branches were also mentioned. With them, this might be worth looking into to save resources (human and machine).
We discussed this a bit at the EPEL Hackfest at Flock. I described the current options for packagers, and also brought up how we’ve done the releng manual tagging process already for the EPEL 10 Haskell stack. Among those in attendance, no one expressed concerns with the status quo. Several people stated they don’t mind performing multiple builds if they want to ship the update to multiple minor versions at the same time.
At this point I think our best path forward is to just document the releng manual tag process, with a description of when it is and isn’t appropriate.