[rabbitmq-discuss] Release Process

[Alexis Richardson]

All,

On a related note we have an excess of large t-shirts but no mediums
or XLs.  I am tempted to print some more.  Any takers.  These fine
garments are black with the logo "Go forth and multiply" and four
RabbitMQ logos in a bouncy rabbity configuration.

As an alternative it has been suggested that we create a LOLrabbit
t-shirt with the logo "WE CAN HAS".  Any takers for this?

alexis


On Wed, Nov 19, 2008 at 2:56 PM, Alexis Richardson
<alexis.richardson at cohesiveft.com> wrote:
> 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
>>
>>
>