[rabbitmq-discuss] Release Process

[Ben Hood]

Michael,

On Wed, Nov 19, 2008 at 3:15 PM, Michael Arnoldus <chime at mu.dk> wrote:
> Just a small but for me rather important question: How will this be
> connected to AMQP versions and interoperability with other brokers and
> clients?

The general idea behind the grouping is to define a meta-release, i.e.
to draw a line accross a set of clients that have all been tested
against one known version of the server. Subsequent to such a line in
the sand, you want to let each component evolve free of the others and
get re-released, until such a time that you want to make a new
meta-release.

Hence the similarity to a Linux distro release - when you get a major
release, you effectively get a set of bits and pieces that are known
to work with each other - but you use curl instead of wget, you may
want to keep up to date with the bleeding edge of curl but couldn't
care less about having a modern version of wget. (No curl vs. wget
flamewar intended :-)

As for the protocol, well, version negotiation is (for all intents and
purposes, please don't quote me on this) part of the protocol, so each
AMQP component should know wether they can gel with another AMQP peer.

So you *could* theoretically do without a meta-release and just rely
on a statement in a log file saying something like version mismatch,
but we feel that it would make it more apparent if we did a publiclly
visible grouping on a periodic basis, e.g. twice per year.

As for 3rd party libraries, it would be down to them to indicate compatibility.

And as for compatibility to other brokers, I think this would have to
indicated on a per-client basis.

Does that answer your question?

Ben