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.
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
