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