[rabbitmq-discuss] Release Process

[Michael Arnoldus]

Ben,

Yes and no :-)

In a perfect world it ought to be sufficient to state the version of  
the protocol the broker and the clients implements to assure they can  
talk to each other. If that didn't work it should be possible to find  
the misbehaving party and fix that like a bug. This would mean no meta  
release until the components comply with a new AMQP version.

While I do understand that the world doesn't work like this, I also  
think it is the right ideal to work towards. In fact I wouldn't  
surprise myself a lot if I some day claimed that not striving towards  
this ideal is the primary reason that many standards aren't worth the  
bytes used to store their description in.

So I guess what I'm worried about is that you will change your focus  
to much towards maintaining internal consistency between your own  
components and forget the standard compliance that should be a very  
important part of this.

Michael

On Nov 19, 2008, at 16:30 , Ben Hood wrote:

> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1912 bytes
Desc: not available
Url : http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20081119/be4162b5/attachment.bin