Release/branch naming; input requested

Release/branch naming; input requested

[Tommi Virtanen]

Ceph is maturing as a product. This brings us new challenges. Up to
this point, we've been putting out a new release every 2-3 weeks, and
only rarely updating an old release. Update releases like 0.42.2 are
still a fairly rare occasion, and the the last number has never
reached 4. However, as we get more and more customers and integrators
deploying Ceph, we need to provide more stable branches with long term
maintenance.

I'm expecting, worst case, we'll be looking at something like this:

- "oldstable": right now, 0.41 plus bugfixes only, because that's what
deployed out there; updates will be rare
- "stable": minor new features will be brought in, but we'll need to
do extensive upgrade testing
- "integration": this will be what our OpenStack Folsom integration
will be against; including e.g. RBD layering
- "latest": new release every 2-3 weeks

On top of these, if you ask for the autobuilt repositories, we have:

- "master": autobuilt all the time
- several branches similar to "master", one per ceph.git branch, that
sometimes are helpful in isolating a bug, or testing whether a code
change fixes it

Now, all of these are relative names. For example, once OpenStack
Folsom is released, we'll need to open a new line of development for
integrating the next version, branching it off the "latest" at a
suitable point in time.

The problem with these relative names is, if you run a system against
"stable", and what "stable" points at changes, suddenly your old &
reliable system thinks it needs to be upgraded. It's better to look up
the current value of stable, and point the installation at that for
updates. Combine this with people tending to be pretty bad at
remembering specific numbers (I was a Debian Developer and I still
can't remember which one is Debian 5.0!), and a new practice emerged:
releases started getting codenames.

Debian originally started giving their releases codenames from the Toy
Story movies: hamm, slink, potato, woody, sarge, etch, lenny, squeeze,
wheezy.

Ubuntu uses largely similar infrastructure, but quickly improved on
that by alphabetizing their codenames: breezy, dapper, edgy, feisty,
gutsy, hardy, intrepid, jaunty, karmic, lucid, maverick, natty,
oneiric, precise; you don't need to remember the order to know
maverick came after lucid. The theme here is adjectives describing an
alliterative animal, Natty Narwhal etc.

OpenStack has picked the same alphabetical idea, using geographic
names near where their per-release development summit is hosted:
austin, bexar, cactus, diablo, essex, folsom.

A company I used to work for picked names of mountains, largely
choosing based on the magnificence of the upcoming release. By that
logic, agel would have fewer new features than matterhorn. The same
theme of mountains could also be used alphabetically. (Back at that
point, a large part of that reasoning was that we left version
numbering completely up to sales; engineering just did a look up of
codename.buildnumber => version string, and we were able to change the
version number of the product without rebuilding.)

On the flip side, Ubuntu also picked up an idea of versioning releases
based on the time of the release: YY.MM, as in 11.10, 12.04. This
works really well for them, because they release only every 6 months,
and they put a lot of effort into being on schedule, so it's always
.04 or .10.



Now, here are my actual questions:

1. What should the "relative" names of the branches be? "stable" vs
"latest" etc. I especially don't like "integration", but I do see a
time where it is not ready for "stable" but still needs to branch off
of "latest".

2. Do we want to use cutesy codenames? Alphabetical? Based on what theme?

3. Do we want to use calendar based names? "I'm using Ceph branch
2012.04"? (Or spell it 2012-04 to avoid confusing with 0.41 style
versions?)

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".

4. What will be worthy of 1.0? Is it when the distributed file system
is solid? Getting out of 0.x would help with separating the different
branches based on major numbers, but I fear that window has closed
already.


Your input is welcome.

Re: Release/branch naming; input requested

[Yehuda Sadeh Weinraub]

On Thu, Apr 26, 2012 at 5:09 PM, Tommi Virtanen
<tommi.virtanen@dreamhost.com> wrote:
> Ceph is maturing as a product. This brings us new challenges. Up to
> this point, we've been putting out a new release every 2-3 weeks, and
> only rarely updating an old release. Update releases like 0.42.2 are
> still a fairly rare occasion, and the the last number has never
> reached 4. However, as we get more and more customers and integrators
> deploying Ceph, we need to provide more stable branches with long term
> maintenance.
>
> I'm expecting, worst case, we'll be looking at something like this:
>
> - "oldstable": right now, 0.41 plus bugfixes only, because that's what
> deployed out there; updates will be rare
> - "stable": minor new features will be brought in, but we'll need to
> do extensive upgrade testing
> - "integration": this will be what our OpenStack Folsom integration
> will be against; including e.g. RBD layering
> - "latest": new release every 2-3 weeks
>
> On top of these, if you ask for the autobuilt repositories, we have:
>
> - "master": autobuilt all the time
> - several branches similar to "master", one per ceph.git branch, that
> sometimes are helpful in isolating a bug, or testing whether a code
> change fixes it
>
> Now, all of these are relative names. For example, once OpenStack
> Folsom is released, we'll need to open a new line of development for
> integrating the next version, branching it off the "latest" at a
> suitable point in time.
>
> The problem with these relative names is, if you run a system against
> "stable", and what "stable" points at changes, suddenly your old &
> reliable system thinks it needs to be upgraded. It's better to look up
> the current value of stable, and point the installation at that for
> updates. Combine this with people tending to be pretty bad at
> remembering specific numbers (I was a Debian Developer and I still
> can't remember which one is Debian 5.0!), and a new practice emerged:
> releases started getting codenames.
>
> Debian originally started giving their releases codenames from the Toy
> Story movies: hamm, slink, potato, woody, sarge, etch, lenny, squeeze,
> wheezy.
>
> Ubuntu uses largely similar infrastructure, but quickly improved on
> that by alphabetizing their codenames: breezy, dapper, edgy, feisty,
> gutsy, hardy, intrepid, jaunty, karmic, lucid, maverick, natty,
> oneiric, precise; you don't need to remember the order to know
> maverick came after lucid. The theme here is adjectives describing an
> alliterative animal, Natty Narwhal etc.
>
> OpenStack has picked the same alphabetical idea, using geographic
> names near where their per-release development summit is hosted:
> austin, bexar, cactus, diablo, essex, folsom.
>
> A company I used to work for picked names of mountains, largely
> choosing based on the magnificence of the upcoming release. By that
> logic, agel would have fewer new features than matterhorn. The same
> theme of mountains could also be used alphabetically. (Back at that
> point, a large part of that reasoning was that we left version
> numbering completely up to sales; engineering just did a look up of
> codename.buildnumber => version string, and we were able to change the
> version number of the product without rebuilding.)
>
> On the flip side, Ubuntu also picked up an idea of versioning releases
> based on the time of the release: YY.MM, as in 11.10, 12.04. This
> works really well for them, because they release only every 6 months,
> and they put a lot of effort into being on schedule, so it's always
> .04 or .10.
>
>
>
> Now, here are my actual questions:
>
> 1. What should the "relative" names of the branches be? "stable" vs
> "latest" etc. I especially don't like "integration", but I do see a
> time where it is not ready for "stable" but still needs to branch off
> of "latest".

reallyold
old
current
next
latest/experimental

>
> 2. Do we want to use cutesy codenames? Alphabetical? Based on what theme?

Yes. Theme should be voted on.

>
> 3. Do we want to use calendar based names? "I'm using Ceph branch
> 2012.04"? (Or spell it 2012-04 to avoid confusing with 0.41 style
> versions?)

No. I don't think it makes much sense. Not at this point at least.

>
> 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.

>
> 4. What will be worthy of 1.0? Is it when the distributed file system
> is solid? Getting out of 0.x would help with separating the different
> branches based on major numbers, but I fear that window has closed
> already.
>

Do we need to have 1.0? I'd say that for the first release that
becomes 'current' with the voted naming scheme we adjust the build
version number to 1.0. After that, every release (not every dev
cycle!) we'd decide whether it's worthy of a major number upgrade or
not. Minor releases can increase the minor version. Fixes on top of
that would go to the 3rd level.
I'm not sure whether it'd work nicely with dev cycle numbering though.

Yehuda

Re: Release/branch naming; input requested

[Sage Weil]

On Thu, 26 Apr 2012, Yehuda Sadeh Weinraub wrote:
> > Now, here are my actual questions:
> >
> > 1. What should the "relative" names of the branches be? "stable" vs
> > "latest" etc. I especially don't like "integration", but I do see a
> > time where it is not ready for "stable" but still needs to branch off
> > of "latest".
> 
> reallyold
> old
> current
> next
> latest/experimental

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

> > 2. Do we want to use cutesy codenames? Alphabetical? Based on what theme?
> 
> Yes. Theme should be voted on.

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?

 argonaut
 bobtail
 cuttlefish
 dispar? dofleini?
 e?
 flamboyant
 ...
 kraken
 ...
 vampire, vulgaris

> > 3. Do we want to use calendar based names? "I'm using Ceph branch
> > 2012.04"? (Or spell it 2012-04 to avoid confusing with 0.41 style
> > versions?)
> 
> No. I don't think it makes much sense. Not at this point at least.

No calendar names.

> > 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.

Yeah, let's keep the versioning orthogonal.  I think it's important that 
the package versions are meaningful and sort well.

The one thing that might be nice is to tag the version codes with the 
stable release name, e.g.

	v0.45argonaut
	v0.45argonaut-1-gf83ca243
	...

so that you can see what you have.  This is just a matter of creating a 
git tag with the appropriate name.  If we do point releases, they could be

	v0.45argonaut.1
	v0.45argonaut.1-1-g3172a72
	...

?

> > 4. What will be worthy of 1.0? Is it when the distributed file system
> > is solid? Getting out of 0.x would help with separating the different
> > branches based on major numbers, but I fear that window has closed
> > already.
> >
> 
> Do we need to have 1.0? I'd say that for the first release that
> becomes 'current' with the voted naming scheme we adjust the build
> version number to 1.0. After that, every release (not every dev
> cycle!) we'd decide whether it's worthy of a major number upgrade or
> not. Minor releases can increase the minor version. Fixes on top of
> that would go to the 3rd level.
> I'm not sure whether it'd work nicely with dev cycle numbering though.

Someday there will be 1.0, but I don't think we need to worry about it 
here.  Personally, I think it should happen when the file system is 
deemed supportable.

sage

Re: Release/branch naming; input requested

[Yehuda Sadeh]

On Fri, May 18, 2012 at 9:32 AM, Sage Weil <sage@inktank.com> wrote:
> On Thu, 26 Apr 2012, Yehuda Sadeh Weinraub wrote:
>> > Now, here are my actual questions:
>> >
>> > 1. What should the "relative" names of the branches be? "stable" vs
>> > "latest" etc. I especially don't like "integration", but I do see a
>> > time where it is not ready for "stable" but still needs to branch off
>> > of "latest".
>>
>> reallyold
>> old
>> current
>> next
>> latest/experimental
>
> 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)

However, now a release means a dev cycle, which is different than
having a few iterations on a single release. So should 'next' be the
next release, or the next output of the current dev cycle?

>  current = most recent release
>  stable = most recent stable release
>
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Release/branch naming; input requested

[Sage Weil]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1664 bytes --]

On Fri, 18 May 2012, Yehuda Sadeh wrote:
> On Fri, May 18, 2012 at 9:32 AM, Sage Weil <sage@inktank.com> wrote:
> > On Thu, 26 Apr 2012, Yehuda Sadeh Weinraub wrote:
> >> > Now, here are my actual questions:
> >> >
> >> > 1. What should the "relative" names of the branches be? "stable" vs
> >> > "latest" etc. I especially don't like "integration", but I do see a
> >> > time where it is not ready for "stable" but still needs to branch off
> >> > of "latest".
> >>
> >> reallyold
> >> old
> >> current
> >> next
> >> latest/experimental
> >
> > 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)
> 
> However, now a release means a dev cycle, which is different than
> having a few iterations on a single release. So should 'next' be the
> next release, or the next output of the current dev cycle?

I think we can keep the current 'release each cycle' plan (which would 
make 'the next release' and 'the output of the current dev cycle' be the 
same thing).  There are still people who will want the bloody (if not 
bleeding) edge of the last sprint output instead of a months-old stable 
release.

And in general, next or current will pretty closely approximate a 'next' 
that means 'the next stable release'.

> >  current = most recent release
> >  stable = most recent stable release
> >
> --
> To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 

Re: Release/branch naming; input requested

[Mark Kampe]

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.

Re: Release/branch naming; input requested

[Jim Schutt]

On 04/26/2012 06:09 PM, Tommi Virtanen wrote:
> Now, here are my actual questions:
>
> 1. What should the "relative" names of the branches be? "stable" vs
> "latest" etc. I especially don't like "integration", but I do see a
> time where it is not ready for "stable" but still needs to branch off
> of "latest".
>
> 2. Do we want to use cutesy codenames? Alphabetical? Based on what theme?
>
> 3. Do we want to use calendar based names? "I'm using Ceph branch
> 2012.04"? (Or spell it 2012-04 to avoid confusing with 0.41 style
> versions?)
>
> 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".
>
> 4. What will be worthy of 1.0? Is it when the distributed file system
> is solid? Getting out of 0.x would help with separating the different
> branches based on major numbers, but I fear that window has closed
> already.
>
>
> Your input is welcome.

FWIW, I think the current Linux kernel versioning scheme should be
considered.  In particular I like that for the most part new features
don't get back-ported to stable series kernels; if you want new
features you need to upgrade.

If you haven't seen it, https://lkml.org/lkml/2012/4/11/779
has a good discussion of issues the kernel versioning attempts
to address.

I think names are cute but essentially useless - what I want
from an identification scheme is to tell at a glance that
"a" is likely to be better than "b".  Numeric "a" and "b" where
a > b does that for me; names don't.

Also FWIW, don't get hung up on 1.0.  Instead, borrow again from
kernel experience - what is needed is careful selection of the
versions that get long-term support.

If you haven't seen it, https://lkml.org/lkml/2011/8/15/5
has a good discussion of longterm kernel support.

-- Jim