In principle I'm +1 on doing a development release. I'd like to see it happen in early June, basically at the same time we do a feature freeze on trunk for the real release. So any big changes that we want to get in to the next big release should be committed to trunk at the time we cut the dev release.
It's like a very early go at an RC. But I like calling it a dev release rather than an RC because for us the RCs are really things we only put out there when we expect/hope that they become the release. In other projects an RC is like a dev release, so doing a dev release can give us the best of both worlds. I'm not particular about the release manager except that this person would have veto rights on any new features for the next big release (if we follow my above logic that trunk should be feature frozen when we cut the dev release), so there is some power to the position though just for a dev release. In general I think the release manager should be a committer but exceptions can always be made. We've never been a group to stick absolutely to rules like feature freezes, and I like that, so other stuff _can_ possibly sneak in after the dev release (I'm sure I'll be pushing for a few) if there is mostly consensus. But it's a good target/ideal to have in mind. Getting a new feature out into the world gives it a chance to bake before the real release. Just thinking about this is lighting a fire under my own ass to get moving on some of the bigger changes I'd like to get in. :) Oh and agree 100% that getting our first mavenized version into the hands of users sooner than later is important. Another good reason for a dev release. JG > -----Original Message----- > From: Todd Lipcon [mailto:t...@cloudera.com] > Sent: Thursday, May 20, 2010 10:31 AM > To: dev@hbase.apache.org > Subject: Development release series? > > Hi all, > > I've been throwing this idea around to a few people individually over > the > last week, but wanted to raise it on the list for a wider discussion: > > I'd like to propose inserting a "development release series" in between > 0.20 > and our next release (the one that will have full durability, > significant > master fixup, etc). In terms of what this release series would be: > > 1) Frequent Releases. We should try to do a release once a month > between now > and the next major release. > > 2) Low Amount of QA. We should not make any guarantees that the > releases > have been heavily tested. They should certainly pass unit tests and > basic > functional tests (eg PE and other cluster smoke tests) but we would not > go > through multi-week rc cycles. > > 3) Clearly communicated "Development" status. We do not want new users > on > this release unless they are aware they are trying what is essentially > a > trunk snapshot. We should feel free to have serious known bugs in these > development releases and not address them until the next release. > > 4) Given the "development" status of this build, I think we should drop > the > "no breaking changes between point releases" restriction. That way > we're > fine to make RPC/API fixups as the series progresses. > > 5) Normal policies regarding license cleanliness, release voting, etc. > Kind > of goes without saying, but we still need to be careful to maintain > proper > licensing, etc, and not let anything slip in that would be Apache 2 > incompatible, etc. > > Now, the reasons I am proposing this: > > 1) We have a vibrant user/contributor community which has a diverse set > of > workloads. The core developer community has a smaller (but growing) set > of > workloads. There have been a few cases where a release has worked great > for > the workloads of the core team, but after a release we've found a > serious > bug that only affects some feature or access pattern that hasn't been > sufficiently tested during development. Doing frequent development > releases > gives reasonable milestones for users to try upcoming releases for > their > workloads and give feedback if there has been a regression. > > Two particular examples of the above are the ExplicitColumnTracker > infinite > loop bug in 0.20.4, and the META caching regression in 0.20.3. > > 2) Given the recent switch to Maven, I think we will find that the > first > post-maven release will bring new difficulties we haven't worked > through in > the past. We should make sure we know how to release off the new build > system, and that all of the various shell scripts and integration > points > still work. Doing some "practice" releases before the real thing will > allow > us to start tackling these problems early. > > 3) It's been quite some time since the last major release. Doing a fast > progression of a few development releases is a good way to highlight > the > recent surge of HBase development and build anticipation for what's > coming. > > 4) On a selfish note, I would like to attempt to include a "beta" > release of > durable HBase packaged in CDH3 in June. We will certainly not be ready > for > the next major release at that point. I can certainly pick an svn > revision > and build my own release off that, but if the version number in CDH > lines up > with a version number of this development series, I think it will > present > less user confusion, etc. > > I am also happy to volunteer myself to release manage at least the > first of > this series. Though I do not have committer access, the Apache rules > generally allow anyone to propose a release tarball, so long as it's > voted > on by the PMC. > > Thanks > -Todd > > -- > Todd Lipcon > Software Engineer, Cloudera
