On Wed, May 4, 2011 at 10:31 AM, Owen O'Malley <omal...@apache.org> wrote: > Here's an updated release candidate for 0.20.203.0. I've incorporated the > feedback and included all of the patches from 0.20.2, which is the last > stable release. I also fixed the eclipse-plugin problem. > > The candidate is at: http://people.apache.org/~omalley/hadoop-0.20.203.0-rc1/ > > Please download it, inspect it, compile it, and test it. Clearly, I'm +1. > > -- Owen
Hey Owen, Thanks for incorporating all the feedback and additional changes. It's great that this release won't be a regression against our previous stable release. I would like to call out that we are not just voting to adopt a particular release, we are starting a new version scheme for the project, doing new feature development on maintenance release branches (before trunk), and we're saying it's OK to release software that hasn't been reviewed by the community. I'd like to hear from our development community not just that we want to do a release from this branch but that we want to adopt these other changes as well. Here's a summary of the major *remaining* issues and a recommendation on how to proceed: 1. There are about ~50 changes that have jiras that are committed to the branch that are not yet in trunk. The next release (0.22) will be a regression against this release, with respect to these particular changes. Recomendation: we should get these changes in trunk before releasing so that new features do not show up in maintenace branches first. 2. There are 192 patches that were committed to the branch without reference to any Jira in the commit message. Some of these may have already been forward ported, but it is very difficult to match them up and evaluate which ones have been committed. Some are troublesome, when spot checking the commits I found some that have been done by non-committers with no public review that introduced an apparent performance regressions (eg see HADOOP-7255). Recommendation: we should update the commit log to make sure there is a jira for each issue, and all changes have been reviewed/committed. This is the way we've always done releases. 3. The new versioning scheme major.minor.point.X the new "X" component allows for new feature development on point releases. Recomendation: we should discuss in a separate thread whether we want to do new feature development on maintenance branches and if so to adopt this new version scheme. Thanks, Eli
