[rabbitmq-discuss] RabbitMQ AMQP 0-9-1 spec branch

[Matthew Sackman]

Hi Chris,

On Sat, May 15, 2010 at 09:28:35AM +0100, Chris Duncan wrote:
> Up until now I have tested against the AMQP 0-9-1 spec RabbitMQ  
> branch as well as 0-8. What are the plans for the 0-9-1 branch? Is  
> there going to be a RabbitMQ 0-9-1 stable release? I don't see much  
> point in continuing to support something that is not going to be  
> included in a stable release.

Our current plans (and note, these can change, and there are not
firm estimates attached to these) are that the next major release will
be the new persister, and the following major release will be the 0-9-1
work. So yes, we are very much committed to the 0-9-1 branch which is
receiving attention now. We are not quite sure just yet whether to
attempt to do multi-protocol (i.e. support 0-8 and 0-9-1 in the same
product) or just drop support for 0-8 all together.

0-9-1 is really a clarification of 0-8 and in nearly all cases where 0-8
is more ambiguous than 0-9-1, we implement the semantics of 0-9-1.
Therefore, the impact to client libraries to move to 0-9-1 should not be
a huge amount of work - obviously all our client libraries will be 0-9-1
ready, and it sounds like the Ruby client is as well (David - please do
*not* drop support for 0-9-1!). There's also an arguement for saying
that old, likely buggy, and unmaintained clients which are currently 0-8
only will either die or be rewritten to support 0-9-1 - that is a good
outcome.

On the other hand, if you, as users of Rabbit and client libraries, are
dependent on a 0-8 client, and moving to 0-9-1 is going to be a massive
issue for you, please let us know - we don't want to cause problems for
people, and certainly don't want to alienate users or the many many
members of this community who have contributed their time, effort and
coding prowess. That said, there is an attraction to forcing some of the
client libraries to receive some attention - for example a number of our
users run into issues because the particular client library they're
using still doesn't support channel.flow. It would definitely be a good
thing if moving to 0-9-1 and dropping support for 0-8 would cause those
libraries to be fixed up, by more than just a change to the version in
the protocol negotiation.

As always, your comments and thoughts are very valuable to us.

Matthew