On Fri, Apr 29, 2011 at 4:09 PM, Owen O'Malley <omal...@apache.org> wrote: > I think everything is ready to go on the 0.20.203.0 release. It includes > security and a lot of improvements in the capacity scheduler and JobTracker. > > Should we release http://people.apache.org/~omalley/hadoop-0.20.203.0-rc0/? >
Based on the discussion I still have the following questions: 1. Does this release replace subsequent releases from branch-0.20? Ie is the goal to replace the 0.20.3 or 0.20.4 release with releases from the branch-0.20-security branches? If not, where does this release fit in? If so, I think we need to do the following before releasing from branch-0.20-security: - Make sure branch-0.20-security-203 contains the patches from 0.20.2, since this branch is based on 0.20.1 it's not clear that it doesn't regress against the current stable 0.20 release. Perhaps the best way to do this is via a rebase. - Make sure branch-0.20-security-203 (and future 0.20 based release branches) contain the patches that were checked in for 0.20.3 and 0.20.4. These branches contain important bug fixes (eg HDFS-1258, HDFS-909, etc) that are not present in this branch, and should be. The expectation of people that checked in patches to branch-0.20 and the users who filed the jiras is that they be fixed in the next stable release. - Remove the 0.20.3 and 0.20.4 fix versions from jira to make it clear what the next release is. 2. What are the compatibility implications? Specifically, do we need to block the next major release (0.22) on getting patches in this release committed to trunk? Should the pace of major version releases be slowed down by minor version releases? 3. Patches normally go through jira, get reviewed, committed to trunk, and then merged to a release branch. Why not use the same process here? I'm concerned that we're setting a precedent that patches don't need to be reviewed and voted on. Given that we're releasing common, hdfs and mapreduce perhaps general@ is a better place than common-dev@ for release discussion. Thanks, Eli
