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

[michaelklishin]

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]

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 (docker-library/official-images#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.
- #734 (comment)

[michaelklishin]

@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]

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:

rabbitmq/Dockerfile-ubuntu.template

Lines 278 to 282 in 4f0a81e

	{{ if env.version | IN("3.13", "4.0") then ( -}}
	RABBITMQ_SOURCE_URL="https://github.com/rabbitmq/rabbitmq-server/releases/download/v$RABBITMQ_VERSION/rabbitmq-server-generic-unix-latest-toolchain-$RABBITMQ_VERSION.tar.xz"; \
	{{ ) else ( -}}
	RABBITMQ_SOURCE_URL="https://github.com/rabbitmq/rabbitmq-server/releases/download/v$RABBITMQ_VERSION/rabbitmq-server-generic-unix-$RABBITMQ_VERSION.tar.xz"; \
	{{ ) end -}}

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+? 👀

[michaelklishin]

@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]

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

[michaelklishin]

@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]

Oh yeah, 4.0.4 is going to ship with Erlang 27 (that's #740 and now docker-library/official-images#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 #742 for now, so 3.13 will be the only version still using the -latest-toolchain artifacts here). 😄

[michaelklishin]

@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]

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). 👍 🙇

I really appreciate your patience as I make sure I understand 😄 ❤️

[michaelklishin]

@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]

Oh no, we're good -- I just misunderstood again! 😂 😭 ❤️

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. 👍

[michaelklishin]

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