rabbit_common release on hex.pm is not compatible with Erlang/OTP 28

[ethunk]

Describe the bug

Problem

The latest version of rabbit_common on hex.pm (4.0.3) fails to compile with OTP 28 due to the removed
street-address macro:

===> Compiling src/rabbit_cert_info.erl failed
rabbit_cert_info.erl:148:15: undefined macro 'street-address'

Fix (Already Exists)

This issue was already fixed in commit 637a2bc (May 19, 2025) which
replaced the macro with the numeric value 17:

{17, "STREET"}, %% macro was removed in OTP28

The fix is included in releases v4.1.0, v4.2.0, etc.

Request

Could you please publish a new version of rabbit_common to hex.pm that includes the OTP 28
compatibility fix?

Currently, Elixir projects that depend on rabbit_common via hex.pm cannot compile with OTP 28, as the
latest published version (4.0.3) predates the fix.

Workaround

For now, users need to either:

• Downgrade to OTP 27
• Use a git dependency (which has build system complications)
• Manually patch the dependency

A new hex.pm release would greatly help the Elixir ecosystem adopt OTP 28.

Thank you!"

Reproduction steps

Environment

• OTP: 28
• Elixir: 1.19.0
• rabbit_common (hex.pm): 4.0.3
• Error: undefined macro 'street-address' in rabbit_cert_info.erl:148

Run mix compile

Expected behavior

A successful compile with Elixir 1.19 and OTP 28

Additional context

No response

[michaelklishin]

@ethunk we explicitly warn users of breaking changes in Erlang 28 that affect RabbitMQ in the docs.

Besides TLS 1.3 connection optimizations, Erlang 28 brings nothing but breaking changes — including a really non-trivial one affecting a Khepri dependency called horus.

So why this should be a priority for our small team while RabbitMQ itself will need non-trivial, multi-person month changes before Erlang 28 can be declared as fully safe to use?

[michaelklishin]

As previously explained in one of the existing discussions, since RabbitMQ does not use rebar3 or Mix — it is older than both of those tools — rabbit_common was published using a number of hacks from infrastructure that no longer exists.

RabbitMQ's own releases were moved to rabbitmq/server-packages, and the hex.pm publishing part, including rabbit_common specifically, was left out.

So to make automatic publishing possible, we'd need to reintroduce rabbit_common, amqp_client and amqp10_client publishing there, and usually this is both a low priority and there are no reasons to do that because for several years now we did not have any breaking changes.

hex.pm is not really an API that provides you a lot of options around manual publishing of .ez files, its authors assume that everyone uses mix and every .ez file-generating codebase is in Elixir using Mix. Well, not RabbitMQ.

So it's a combination of constrained resources of a small team and hex.pm's publishing mechanism that completely ignores the needs of projects that use erlang.mk and Erlang.

If the Elixir community so badly needs to use Erlang/OTP 28, they should step up and help make publishing easier for the RabbitMQ team, not file the same issue over and over.

[michaelklishin]

I have managed to publish rabbit_common, amqp_client and amqp10_client manually with generated and temporarily tweaked .app.src files, both 4.1.5and 4.2.0 versions.

In case any local compilation matters during the publishing process, I've made sure to run all this on the latest patch release of Erlang 26.

@ethunk let me know if the new versions work on Erlang 28 in your apps.

[michaelklishin]

Looks like the packaging code included a symlink to ../../rabbitmq-components.mk, which causes rebar3 compile to fail when compiling the dependency. It's a very reasonable security measure.

I will have to yank the version and find a way to exclude the link.

[michaelklishin]

Round two:

• https://hex.pm/packages/rabbit_common
• https://hex.pm/packages/amqp_client
• https://hex.pm/packages/amqp10_client
• https://hex.pm/packages/amqp10_common

The Erlang port of our tutorials work with these republished 4.2.1 and 4.1.6 versions.

When RabbitMQ 4.2.1 and 4.1.6 releases are out in a few weeks, those packages won't be updated. Chances are they won't have any changes at all, and almost certainly won't have any public API or other functional changes.

Then eventually they should start matching the latest RabbitMQ release, I won't promise any specific dates or patch numbers.

If there's a positive side to this hex.pm publishing gymnastics that's taken a few hours end-to-end, it is this: I now know how to automate this in rabbitmq/server-packages with a lot less effort compared to our original Concourse-based implementations. What I do not yet know how is how to do it reasonably test this without polluting hex.pm with lots of -alpha.{n} builds.

[lukebakken]

I'd say pollute away with alpha builds 👍