+1 on semver. The important thing for people to realise with semver is that you bump the major number *every time you break backwards incompatibility*. Not just when you think you've added something "reasonably large". Big, big difference. And totally sensible.
Also, you mention cutting the release branch after all the features have been landed. What about doing it the other way around. As soon as you release, cut a new release branch. Anybody who wants to get features into the next release has to merge them into the release branch. Implement a merge policy that only accepts those merges when they come with full tests, documentation, etc, etc. We're trying something similar with CouchDB... On 1 November 2012 18:23, Chip Childers <chip.child...@sungard.com> wrote: > On Thu, Nov 1, 2012 at 2:15 PM, John Burwell <jburw...@basho.com> wrote: > > All, > > > > Has their been any consideration given to adopting semantic versioning ( > http://semver.org/)? It lays out a nice contract to express the impact a > release by by assigning meaning to version element (e.g. all 1.x.x releases > are API compatible). This approach is beginning to be adopted by other > projects (e.g. Wicket). Also, it doesn't preclude fix time deliveries. > > Semantic versioning is very much in line with the current version > numbering discussion, but refines it to focus on the public API > itself. I would classify this as being the CloudStack API for now, > and not necessarily the AWS API (since that will mature over time, but > we are tying ourselves to Amazon's API change process). > > IIRC, semver allows minor version bumps can happen even if new API > calls are made available, as long as it retains backward compatibility > with previously released versions within the major version family. I > think this would work for us quite nicely. > > It will also help force community rigor around maintaining backward > compatibility for the existing API calls! > > I'm +1. Others? > > -chip > > > Thanks, > > -John > > > > On Oct 31, 2012, at 11:05 PM, Chip Childers <chip.child...@sungard.com> > wrote: > > > >> 4.0.0 was hard, because we couldn't just say "well, these are the > >> fixes we did on the legal front that made it in." It was an all or > >> nothing proposition, which was the primary struggle. > >> > >> As long as we keep ourselves in legal order, we limit future releases > >> to the feature inclusion/exclusion question. That is easier to deal > >> with IMO. > >> > >> - chip > >> > >> Sent from my iPhone. > >> > >> On Oct 31, 2012, at 10:54 PM, Will Chan <will.c...@citrix.com> wrote: > >> > >>> +1 > >>> > >>> I would love to make sure that we are strict on the time-based > release. I know that I would love to continue to add more and more > features on each release and I'm sure Citrix would love to incoporate > features for their commercial releases but if we are not strict with this, > we will just keep slipping. Other than that, I am in favor of this. > >>> > >>> Will > >>> > >>> ________________________________________ > >>> From: Marcus Sorensen [shadow...@gmail.com] > >>> Sent: Wednesday, October 31, 2012 6:02 PM > >>> To: cloudstack-dev@incubator.apache.org > >>> Subject: Re: [DISCUSS] releases going forward > >>> > >>> +1, this would line up nicely with having a major rev once a year with > 2 or > >>> 3 minor revisions in between. > >>> Then maybe once a month someone rolls up any applicable bugfixes and > we do > >>> a point release? Do we want to have some procedure around that, like a > mini > >>> vote? > >>> On Oct 31, 2012 6:26 PM, "Chip Childers" <chip.child...@sungard.com> > wrote: > >>> > >>>> On Thu, May 24, 2012 at 10:45 AM, David Nalley <da...@gnsa.us> wrote: > >>>>> So I think we have consensus around a few things already - lets > >>>>> highlight those: > >>>>> > >>>>> * Time based releases > >>>>> * Versioning scheme: > >>>>> X.Y.Z > >>>>> > >>>>> - X : increases when there is a "major" change in architecture or > some > >>>>> major new feature > >>>>> - Y : increases with every release every 6 month (reset when X > increases) > >>>>> - Z : increases when there are "must fix bugs" or annoying bugs that > >>>>> get fixed in a release branch (reset when Y increases) > >>>>> > >>>>> > >>>>> ===== What we don't yet have consensus on ===== > >>>>> > >>>>> * What the time period is on releases > >>>> > >>>> Digging this out of the past, IIRC, we never got around to resolving > >>>> the time period for releases. We should come to a conclusion on this > >>>> topic! I'd like to propose that we follow a 4 month release cycle for > >>>> non-bug fix releases. > >>>> > >>>> Generally, it would mean a schedule that would look something like > >>>> this (M=Month and W=Week): > >>>> M1 through M2 - Features are being developed in branches, and merged > >>>> into master over the course of these two months > >>>> M2 W4 - Feature freeze (and release branch is cut). > >>>> M3 W1 through M4 W1 - Doc Updates and Testing > >>>> M4 W1 - Docs Freeze > >>>> M4 W2 - Final regression testing / bug fixes / doc fixes > >>>> M4 W3 - First RC cut and opened for voting... Wash rince repeat until > >>>> an RC is voted to be released > >>>> > >>>> This proposal might lean a bit heavily towards documentation and > >>>> testing, but my opinion is that features are going to be developed > >>>> outside of this release cycle. What matters, is when they land in > >>>> master, and when they are scheduled to be released. IMO, this type of > >>>> schedule provides us with the ability to have predictable periods of > >>>> time for stabilization and documentation. > >>>> > >>>> If the actual time period of the release is something other than 4 > >>>> months, then I would argue for a similar schedule in the ramp up to > >>>> the first RC. > >>>> > >>>> If we can reach a consensus on this, I'll be happy to draft up a > >>>> schedule with specific dates for our 4.1.0 release. > >>>> > >>>> Thoughts, comments, flames? > >>>> > >>>> -chip > >>>> > >>>>> * What the version number for the first Apache release should be (to > >>>>> be fair we haven't really discussed this.) > >>>>> > >>>>> So lets start with the easy one, the version number - should we > target > >>>>> 3.1.0 or 4.0.0 or something else entirely? I could be swayed either > >>>>> way. > >>>>> > >>>>> On the release time period - as a packager for 20-30 packages in > >>>>> Fedora I am certainly sympathetic to release cycles, and realize that > >>>>> virtually all of the community distros (save Debian which is on a two > >>>>> year release cycle) are on a 6 month cycle. That said I don't know > >>>>> that we can necessarily be married to what the distros are doing. I > >>>>> also look at projects like subversion which are tossing out releases > >>>>> approximately every 60 days - and I don't see any distro that doesn't > >>>>> carry subversion (though admittedly very different projects in > >>>>> virtually every respect) I think every 3-4 months makes sense to me, > >>>>> but again that's just me - gives us a slightly faster iteration but > >>>>> hopefully not removing towards an unmanageable release cycle speed. > >>>>> > >>>>> Another question is - how long do we support any given release > >>>>> line......e.g. if I embark on 5.2.0 (completely made up version > >>>>> number, but assuming the above version scheme) how long will I be > >>>>> guaranteed bugfixes for 5.2.x. Perhaps it's too soon to even ask that > >>>>> question - we haven't even pushed a single release out, but something > >>>>> to think about. > >>>>> > >>>>> Thoughts, comments, flames? > >>>>> > >>>>> --David > >>>> > > > -- NS
