For context: There is a blanket Updates Policy exception for library-only Rust packages in Fedora (see https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#rust ). These packages are only useful for building actual applications (which are not covered by the policy). Keeping the versions of these source-only packages in sync between Fedora branches reduces the maintenance burden a lot, and also makes it easy to backport potential fixes for bugs and security issues.

I had originally planned to handle EPEL 10 minor branches differently, i.e. only merge library updates to epel10.x branches as needed (i.e. for shipping bug fixes or security updates for applications). However, it was pointed out to the that the reason we don't do this in Fedora also applies here: it makes shipping any application updates on the trailing branches much harder and much higher overhead. This might not be desirable, as it could, for example, introduce arbitrary delays for shipping security updates, because large parts of the dependency tree might have diverged from the leading epel10 branch already.

Note that we already treat the epel9 branch as kind of a "rolling release" for these purposes, even though I think this was never signed-off-on by EPEL stakeholders (this predates my involvement with Rust packaging).

Essentially, I'm asking if it would make sense to apply an Updates Policy exception to source-only Rust crate packages in EPEL similar (or equivalent) to the one that already applies for stable Fedora branches.

Updating both epel10 and epel10.y branches would result in a little bit more work on an ongoing basis, but would make shipping security or bugfix updates potentially much much easier (and faster). And at the same time, it would be good to have a "this is ok" for what has been already happening in the epel9 branch for the past few years :sweat_smile: