I am developing a snap for
rabbitmq-server and would like to support several major versions.
Currently various Ubuntu LTS offer a range of versions from
3.9. Transitioning an existing system from deb to snap would be easier if the snap came in multiple channels that cover those deb versions.
Per Process for aliases, auto-connections and tracks, we need a 1-week voting/discussion period, so I’ll check back on the discussion and votes in a few days.
I have three questions before casting my vote.
- What’s rabbitmq-server’s release cadence, how often is a new major version (potentially requiring a new track) released? is this documented somewhere by upstream? (Fine to link to upstream documentation if they have such a policy).
- Is there some commitment from upstream on maintenance of old versions? e.g. is 3.6.x still supported with security updates? will it continue to be supported now that newer versions are out, and for how long?
- Are new versions backwards-incompatible? meaning, if I was running 3.6 and I install 3.9, will that just work, or do I need to migrate my data/configuration, or will things break horribly?
- The release cadence does not appear to be governed by policy but has been about 2 years except for the latest (3.10) which was released about 1 year after the previous release (Releases)
- Yes, upstream supports a “general support” model for their releases which covered 34 months for each of the last 2 releases
- Generally, upstream supports
N+1 upgrades only, i.e. upgrades from one major release such as for example from
3.6 to the next major release
3.7. During upgrades the cluster needs to be taken offline but are generally not disruptive beyond such outages. Note that some specific versions require specific upgrade strategies, e.g. priority queues from
3.7 and beyond .
As you will notice, version
3.6 is not supported by upstream at this point. The reason I started with
3.6 was to support the version Ubuntu ships with Bionic to allow for a drop-in replacement on such systems.
I hope I was able to clarify all of your questions.
Is there anything else you would like to know?
Hi, I’m +1 to creating these tracks (3.6 and 3.9).
Do any other @reviewers have time to cast a vote so we can proceed?
+1 to 3.6 and 3.9 tracks for rabbitmq-server.
@nicolasbock I’ve created tracks
Thanks everyone for the help!
I am not clear on how to “correctly” work with tracks. I had imagined that I would use branches in the GitHub repository that contains the
snapcraft.yaml definition and that I would be able to connect those branches to the tracks on snapcraft.io. I don’t see how that it is possible though. The
builds page seems to only track the default branch of the repository.
What is the suggested workflow for this use case?