I think that sounds like a good idea. I'd possibly be more aggressive in removing them though. E.g. release 12.x a bit earlier than proposed if possible with them removed already, whilst still releasing 11.x concurrently for a final transition period from that point on. Anyone still transitioning can continue using 11.x in that time. Anyone that already transitioned uses 12.x.
Or even make that 11.x and a future version of the 10.x stream. Further to your client point, the project actually has no active AMQP 0-x clients anymore. The focus was on 1.0 clients for over a decade now. For AMQP 0-10 in particular, I'm also not aware of any clients outside of Qpid's, and if that is true then there are none still active for 0-10. Obviously there are many other AMQP 0-9[-1] clients though. Robbie On Mon, 17 Aug 2026 at 15:40, Daniil Kirilyuk <[email protected]> wrote: > > Hi Colleagues, > > Broker-J currently supports AMQP 0-8, 0-9, 0-9-1, 0-10, and 1.0. > > We would like to propose the following gradual retirement of the AMQP 0-x > protocols: > > - Broker-J 11.0, targeted for 2027: declare AMQP 0-8, 0-9, 0-9-1, and > 0-10 deprecated. They would remain functional during the 11.x line, but > users would be encouraged to migrate to AMQP 1.0. > > > - Broker-J 12.0, targeted no earlier than 2028: remove support for > accepting AMQP 0-x client connections. > > The motivation is to concentrate development, testing, maintenance, and > security work on AMQP 1.0. The Qpid JMS AMQP 0-x client has already been > retired. > > Before deciding on this direction, we would particularly like to understand > the remaining use of AMQP 0-x with Broker-J: > > - Which AMQP 0-x versions are still used with Broker-J? > - Which client libraries and versions are involved? > - Are there migration blockers that prevent using AMQP 1.0? > > The proposed removal in 12.0 concerns AMQP 0-x wire-protocol support. Any > removal would need to include a documented and safe upgrade path for > existing Broker-J installations. In particular, we would need to account > for existing port configuration, durable messages, and other persisted data > that use legacy metadata formats. > > This is a proposal for community discussion and not a final decision. > > Kind regards, > Daniil Kirilyuk --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
