Re: Release/branch naming; input requested

[Mark Kampe <mark.kampe@inktank.com>]

On 05/18/12 09:32, Sage Weil wrote:

> I think we can limit the relative branches to:
>
>   master = integration, unstable, tip, bleeding edge (same as now)
>   [next] = next upcoming release (same as now)
>   current = most recent release
>   stable = most recent stable release

We have already signed one contract that obligates us
to years of support, and once customers go into production
they will be loathe to move to each new stable release as
it comes out.  Thus, I fear that we will be maintaining
multiple stable releases ... but once a stable release ceases
to be the newest, the bar on what has to be back-ported to
it can be significantly raised, lowering the cost.

> I like Yehuda's suggestion of cephalopods, or other interesting sea
> creatures.  As he points out, though,
>
>    http://www.thecephalopodpage.org/taxa.php
>
> suggests that there may not be enough good choices that are strictly
> cephalopods, though.  Although it might be ok?
> ...

I don't have an opinion about themes, but I do suggest that they
should be memorable and easily pronounced ... and taxonomic
family names do not always have those characteristics.

>>> 3. What do we do with version numbers? With a 2-3 week iteration,
>>> we'll end up with something like 0.41.x, 0.56.x for Folsom integration
>>> (less than a year from now), and 0.57, 0.58 etc for "latest".
>>
>> We can keep those, they are completely orthogonal. These are exactly
>> what they are: dev cycle numbers. I'm not too afraid of big numbers
>> there, as they become uninteresting once you have the other naming
>> scheme. They have the nice property of monotonically increasing which
>> is useful internally.

Given that most releases will only get a subset of what is in builds,
I too think that builds should be orthogonal to releases.