[rabbitmq-discuss] Release Process

[Eran Sandler]

I think I prefer the Ubuntu style.


Whenever a new RabbitMQ server is about to be released all clients that 
should be bundled should be "frozen" so that all compatibility issues 
with these clients can be verified/fixed for the specific server release.


More advanced users can continue to advance in client versions if there 
are improvements/fixes/etc.


On the next server release the same process repeats to "freeze" the 
versions of clients that will be used in the server release.


Regarding code names, we need Bunny names ;-)

Or maybe Bunny breed names 
(http://en.wikipedia.org/wiki/List_of_rabbit_breeds) :-)


Eran


Ben Hood wrote:

> Hi all,
>
> The Rabbit development team has a question which the community may be
> able to help us with.
>
> ATM we are going through the process of finishing off the last
> remaining items for the next release.
>
> After this release has been made we would like to continue the process
> of separating the client releases from broker releases.
>
> The reason why we want to do this is to make the release procedure
> less monolithic and we don't want to have upgrade clients in a lock
> step fashion.
>
> This will (hopefully) increase the agility of the overall release
> process and thereby increase the frequency of releasing new
> functionality and bug fixes.
>
> What we don't know is if we release clients at different intervals to
> the broker, how is the average user going to know what version works
> with what.
>
>
> The Current Rabbit Ecosphere
> --------------------------------------------
>
> - Broker 1.4.x
> - Java Client 1.4.x
> - .NET Client 1.4.x
>
>
> Where We May End Up
> -----------------------------------
>
> - Broker 1.x.y
> - Java Client 2.m.n
> - .NET Client 3.j.k
> - (Erlang Client x.y) ?
> - (Adapter p.q) ?
>
>
> The problem with letting all of the different versions run free is
> that knowing what works with what becomes less apparent to casual
> observer.
>
> So for example, how is the average person who doesn't know Rabbit from
> a bar of soap supposed to work out that version 2.1.3 of the Java
> client has been tested and verified against version 1.7.8 of the
> broker?
>
> Another way to view this would be a compatibility matrix, which would
> give a slightly different perspective because it would be an overview
> of every release, rather than just a slice through certain versions.
>
> One initial thought is to make periodic group releases. These would be
> bundles of the components that are known to work with each other. This
> would be similar to say a Ubuntu release (e.g. version 8.10 contains
> gcc 4.3.2, awk 3.1.6, grep 2.5.3 etc).
>
> In this scenario, we would do a seasonal umbrella release with a
> particular name or version. It could as simple as a web page that
> contains links the particular versions of the consituent parts.
>
> So if anybody has any thoughts about this or the release process in
> general please let us know. It could as simple as telling us what
> naming scheme for the umbrella would be the most appropriate, e.g.
>
> - Ubuntu Style: Year-Month
> - Erlang Style: 12B-4
> - Use code names like Roger, Warren, Bugs, Eminem, ....., (your favourite name)
> - ?
>
> Any comments or suggestions are welcome.
>
> Ben
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.rabbitmq.com/pipermail/rabbitmq-discuss/attachments/20081119/d0535560/attachment.htm