search

docker-library / rabbitmq

Docker Official Image packaging for RabbitMQ
http://www.rabbitmq.com/
MIT License
785 stars 417 forks source link

Heads-up: RabbitMQ 4.0.4 has shipped using new release infrastructure #739

Closed michaelklishin closed 1 week ago

michaelklishin commented 1 week ago

This is not an issue but rather just a heads-up for @tiagomtotti @yosifkit, in case you folks see a surprising behavior of a 4.0.4 build. It is unlikely but we cannot rule it out.

RabbitMQ 4.0.4 has been build using new publicly available release workflows.

The -latest-toolchain packages are still available. At some point we wanted to drop them and build everything on a recent toolchain but then we figured this image uses them and so we can at least consider doing it later.

The latest toolchain packages are currently produced on Erlang 26.2. This is because we need to ship an Erlang 27-compatible set of packages first, then update build-env-images to use them (consume them via apt from our Cloudsmith mirrors), then produce a release. So there will be a certain delay.

In any case, this is the first GA release produced by a new set of workflows that are now open source:

  1. rabbitmq/build-env-images
  2. rabbitmq/server-packages

and we cannot completely rule out any discrepancies even though just I personally have tested these packages five times, and during the first two have found a couple of issues.

yosifkit commented 1 week ago

Thanks for the heads up. It looks like all the build tests were successful, so we have an updated Dockerfile. But we haven't quite published the images (https://github.com/docker-library/official-images/pull/17954).

Regarding 4.0.4, should we swap to erlang 27 for 4.0.4 or not until 4.0.5?

I suggest that we switch this image to Erlang 27 after RabbitMQ 4.0.4 ships. - https://github.com/docker-library/rabbitmq/issues/734#issue-2619472754

michaelklishin commented 1 week ago

@yosifkit I think it should be fine for this image to adopt Erlang 27 starting with 4.0.4. At least we are not aware of any known outstanding issues on our side, and likely nothing major and yet unresolved in Erlang/OTP itself.

tianon commented 1 week ago

The -latest-toolchain packages are still available. At some point we wanted to drop them and build everything on a recent toolchain but then we figured this image uses them and so we can at least consider doing it later.

Just to make sure I'm understanding clearly, you want to drop that for 4.0, or just 4.1+?

ie, we have this if statement already:

https://github.com/docker-library/rabbitmq/blob/4f0a81ee7d0e9264a4735746da07b851fa8dac58/Dockerfile-ubuntu.template#L278-L282

Should we plan to make that more explicitly version-specific so that some future 4.0 release (4.0.4, even?) switches, or should we keep it and only do that for 4.1+? :eyes:

michaelklishin commented 1 week ago

@tianon we consider current 4.0.x patch releases, in fact, not just 4.0.4, to be Erlang 27-compatible. So you are welcome to use it in 4.0.x.

We already produce (but not yet publish to repos) RPM packages and Debian should be ready soon. So yeah, the future is certainly "27-oriented", although right now there are no plans to require it for 4.1.

tianon commented 1 week ago

Ah, that makes sense, so we could even swap that for 4.0.4 :eyes:

michaelklishin commented 1 week ago

@tianon I mean, if 4.0.4 could ship with Erlang 27, I personally think it'd be great but if no, 4.0.5 will certainly be ready.

tianon commented 1 week ago

Oh yeah, 4.0.4 is going to ship with Erlang 27 (that's #740 and now https://github.com/docker-library/official-images/pull/17954), I'm just clarifying which URL we should download RabbitMQ from -- my understanding is that -latest-toolchain is the Erlang 26-built URL and that the other is the Erlang 27-built version, so we can switch URLs now too (which I've opened https://github.com/docker-library/rabbitmq/pull/742 for now, so 3.13 will be the only version still using the -latest-toolchain artifacts here). :smile:

michaelklishin commented 1 week ago

@tianon currently -latest-toolchain is 26.2.x-based but I hope that for 4.0.5 it will be 27.1.x-based. I think this image should use -latest-toolchain in general. As for version transitions periods like this one, I trust your judgement.

tianon commented 1 week ago

Ah, OK, that tracks now, so #742 should be closed and we'll stick to the other URL only for 4.1+ (which doesn't have -latest-toolchain artifacts). :+1: :bow:

I really appreciate your patience as I make sure I understand :smile: :heart:

michaelklishin commented 1 week ago

@tianon I can produce a 4.1.0-beta.2 immediately, and it will contain a -latest-toolchain package, if that would save you some time. It takes about 10 minutes.

tianon commented 1 week ago

Oh no, we're good -- I just misunderstood again! :joy: :sob: :heart:

So the next (pre)release of 4.1 will have a -latest-toolchain URL, and when it does, we should go back to using it across all versions. :+1:

michaelklishin commented 1 week ago

@tianon 4.1.0-beta.2 is out and includes a -latest-toolchain package.