rabbitmq yum repositories by major version(s)

[LangJV]

Is your feature request related to a problem? Please describe.

The RabbitMQ Repos are provided in a uniform fashion. All releases and version(s) are included in the repository for all active major versions. This is simple, but presents some issues with trying to avoid major upgrades.

A yum update can unintentionally push us form, say, RabbitMQ 3.11 to RabbitMQ 3.12 (major version upgrade) without much thought. This can introduce feature changes unintentionally and suddenly when the goal was simply to get the latest version of 3.11.X which is also available in the repo - but automatically superseded unless you do some yum update gymnastics beyond a simple "yum update"

We also recently had an issue where a yum update was failing on dependencies because 3.11.x isn't compatible with erlang 26, but that recently was added to the erlang repo as a new major version. This necessitated more yum gymnastics to make it install

Describe the solution you'd like

Our primary consumption is via Yum/DNF on RHEL 8/9 and RockyLinux and AlmaLinux (and likely other EL derivatives)
A common practice by many other projects and vendors we work with is to have "major version" or "channel" repositories available typically in addition to the "unversal/latest" ones.

As a quick example, RabbitMQ 3.12 is considered a "major version" So would it be possible to have a repository available to consume that is like "rabbitmq-3-12" another that is rabbitmq-3-11 another that is rabbitmq-4-0" and so on (and the same for erlang). This would allow us (at our discretion) to specifically pin to a Major version, or channel. That repository would ONLY contain that major version, and its updates. To move to another version, we would explicitly update our repository/URL. This allows us to "safely" execute regular yum updates to get the latest dot-releases without risk of bumping to a new major version unexpectedly.

Describe alternatives you've considered

Our hacky workarounds thus far have been to use yum "excludes" notation to exclude what we think the next version(s) will be with wildcards, and/or yum versionlock. This "works" but is less than optimal.

Additional context

Some examples of other repositories we consume that follow this model today:
Puppet Agent:
(Latest): https://yum.puppetlabs.com/puppet/el/8/x86_64/index.html
(6): https://yum.puppetlabs.com/puppet6/el/8/x86_64/index.html
(7): https://yum.puppetlabs.com/puppet7/el/8/x86_64/index.html

PostgreSQL:
(12): https://download.postgresql.org/pub/repos/yum/12/redhat/rhel-8-x86_64/
(13): https://download.postgresql.org/pub/repos/yum/13/redhat/rhel-8-x86_64/
(14): https://download.postgresql.org/pub/repos/yum/14/redhat/rhel-8-x86_64/
(15): https://download.postgresql.org/pub/repos/yum/15/redhat/rhel-8-x86_64/

Kong:
(1): https://download.konghq.com/gateway-1.x-rhel-8/
(2): https://download.konghq.com/gateway-2.x-rhel-8/
(3): https://download.konghq.com/gateway-3.x-rhel-8/

Foreman:
(3.0) https://yum.theforeman.org/releases/3.0/el8/x86_64/
(3.5) https://yum.theforeman.org/releases/3.5/el8/x86_64/
(3.7) https://yum.theforeman.org/releases/3.7/el8/x86_64/

[michaelklishin]

There are no plans to provide separate repositories per version. On Cloudsmith, a few latest patch releases of two or three latest minors are provided. The Cloudsmith mirror and PackageCloud (if it comes back as a permanent option, which remains to be seen) store the entire archive of releases.

You can pin package version. There are no significant incompatibilities between 3.10 and 3.11, or 3.11 and 3.12, because all potentially breaking changes are hidden behind feature flags. Incompatibility
with client libraries are extremely rare and usually happen every few years, if at all (RabbitMQ Java and .NET clients can still connect and perform key operations against RabbitMQ 2.0 nodes from 2011).

Our team is very small. We do not have the cycles to split the repositories.

Those who want to have full control can host their own mirror and choose what exactly is or is not available there.

[michaelklishin]

The gist focuses on apt mirroring but for dnf/RPM repos, the process is very similar. I will put together an RPM mirror example in the next few days and leave a link here.