On Tue, May 3, 2011 at 1:31 PM, Owen O'Malley <omal...@apache.org> wrote: > > On May 3, 2011, at 9:35 AM, Eli Collins wrote: > >> Do all changes for 0.20.2xx release go through branch-0.20-security, >> then get merged to a particular -2xx branch? > > I've discussed this before on the lists, but here goes: >
Thanks. I should have mentioned that I followed the thread below but it was not clear that eg all changes have to go through -security to ensure a -20(n+1) branch has the changes from -20n. http://mail-archives.apache.org/mod_mbox/hadoop-common-dev/201103.mbox/%3ce59d9a63-cc4f-4e00-97c0-b11c84c23...@apache.org%3E > branch-0.20-security is the major branch and all changes need to be committed > to it. > Thanks for clarifying. > The branches off of branch-0.20-security, namely branch-0.20-security-203 and > branch-0.20-security-204 are the minor branches, which are branched off of > branch-0.20-security every month or two. Within a minor branch there are only > bug fixes. > Why the new branches instead of releasing from branch-0.20-security the way previous release branches (eg branch-0.20) have worked? > So this release, we are trying to get out the door is 0.20.203.0. A bug fix > to it would go into 0.20.203.1. New features like disk fail in place go into > 0.20.204.0. > Shouldn't new features go to trunk and then the next minor release? According to the project's current version scheme (http://wiki.apache.org/hadoop/Roadmap eg major.minor.point), a point release (eg the 203 in 0.20.203) "do not introduce new features or make other improvements other than fixing bugs." Is this a proposal to make branch-0.20-security a feature branch that does releases, and the new version number is necessary to allow for new features? Doesn't this allow for releases from branch-0.20-security and trunk to diverge in terms of feature set? I think people would prefer we spend our energy putting new features (not yet in trunk) in trunk so we don't create divergent releases. Creating a new branch for new features seems like it will prolong our current situation. >> Why is there a new 4th component to the version number? > > The problem is that we need minor versions and there isn't space in the > current scheme. It would probably be clearer, if we called this release 1.0. > Then this looks like: > > branch-1 > branch-1.0 > branch-1.1 > > with point releases off of it. When I floated the idea of using 1.0 last > time, there was more consensus around using the 0.20.20X.Y naming. > I remember there being resistance to calling it 1.0 but I don't remember consensus on a new feature branch or 4 part version scheme. Not sure mirroring the YDH version numbers is what's most sense for an Apache release: http://www.flickr.com/photos/steve_l/5560919873/in/set-72157626356732562 Arun's proposal of using 0.20.100 seemed more logical. >> I noticed a 0.20.205.0 fix version showed up recently. Where's the >> branch for that? > > It hasn't branched yet, but it will come off of branch-0.20-security. > So a fix for 0.20.205.0 (like any fix for a version not yet branched) only gets checked into branch-0.20-security. Makes sense. Thanks for the clarifications. Thanks, Eli
