A Discussion on RabbitMQ Versioning

[adamncasey]

At the moment, as an observer, RabbitMQ versions seem to be numbered like this:

• New big features in RabbitMQ tend to happen at boundaries like 3.8.x -> 3.9.x. These seem to come around every year or two.
• Bug fixes, but also small features & small behaviour changes appear to happen at boundaries like 3.8.1 -> 3.8.2. These are released quite regularly.

At times the smallest decimal point releases (I'm avoiding using semver terms like patch or minor) introduce new features and make (typically small, sometimes breaking) behaviour changes, which is surprising compared to other versioning systems.

I had an interesting chat with @gerhard about this, and he said @dumbbell might also be interested in this topic

I have two actual questions on this below, but I'm also interested in a wider discussion 🙂

1. Are there any conversations going on at the moment within the RabbitMQ core team on this topic? Anything public/anything which could be public that can we see?

2. Is there any appetite for moving towards maintaining exact backwards compatibility (e.g. migration-free rolling upgrades, and no breaking changes) for patch releases. Then release more frequent major versions, and minor versions of RabbitMQ.

[michaelklishin]

1. There is and there have been for years.
2. RabbitMQ teams at VMware are contractually obligated to maintain a minor version of a certain period of time. This is not an R&D decision and we were unable to reduce the period to something we'd be comfortable with. If the period remains what it is, we estimate that we'd be on the hook for maintaining five or six or more release series in parallel. This is not realistic.

[dreiucker]

@adamncasey Thank you for taking up this discussion. I also contacted @gerhard for similar reasons.

Trigger for that discussion

If a customer upgrades to a 3.8 version and therefore also comes across the consumer_timout behavior change that was introduced with the 3.8.15 release. I have to admit that coming across a breaking change advertised as an enhancement in a minor release wasn’t a pleasant surprise. My personal interpretation from the posts in the issue was that other customers didn't favor introducing a breaking change in a minor release and would also like to avoid that in the future.

Versioning

As @michaelklishin answered above there are responsibilities of maintenance that come with the release of a minor version. It is true that as a customer I favor to have the version supported for a longer amount of time. Especially in an enterprise environment upgrades tended to be slow due to the restrictions, amount of integrations, size, etc ...

However, putting breaking changes into smallest decimal point releases has some downsides that for both RabbitMQ and it's customers:

• Customers have to do intensive testing, changing their code basis and adding workarounds on every small upgrade to make sure that doesn't kill their current setup, which costs time and money they could spend otherwise
• As a result the pace customers upgrade their systems is slower than for systems they can rely on the versioning
• Emergency upgrades due to newly discovered security breaches are adventurous, because in that case the time for testing and discovering breaking changes is limited
• It interferes with CI/CD and DevOps since the effort to automate around RabbitMQ increases due to the reasons named above
• It adds unnecessary discussions and support effort until every last user has understood and adjusted to new versions

And yes I'm aware that not every customer is slower, eager to keep their system consistent etc.

Communicating breaking changes

If the versioning would not be changed the way breaking changes are shipped could still be improved. And if versioning would be changed even more important to reliably identify breaking changes.

I was surprised there wasn't any word in the release notes that a breaking changes was shipped. I saw that the concept of marking breaking changes were used before in 3.6.16 and that also PRs get reviewed on that basis.

So how can we make sure that they are getting identified and communicated?

I'm glad there are other people interested in that topic and hope we can agree on improvements so all participants can benefit from the changes.