[rabbitmq-discuss] Release Process

Alexis Richardson alexis.richardson at cohesiveft.com
Wed Nov 19 14:56:32 GMT 2008


On Wed, Nov 19, 2008 at 2:48 PM, Eran Sandler <eran.sandler at gmail.com> wrote:
>
> Regarding code names, we need Bunny names ;-)
>
> Or maybe Bunny breed names
> (http://en.wikipedia.org/wiki/List_of_rabbit_breeds) :-)

This is an excellent suggestion.

Of course the next Ubuntu release is jaunty jackalope too.

alexis













> 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
>
>
> _______________________________________________
> rabbitmq-discuss mailing list
> rabbitmq-discuss at lists.rabbitmq.com
> http://lists.rabbitmq.com/cgi-bin/mailman/listinfo/rabbitmq-discuss
>
>




More information about the rabbitmq-discuss mailing list