Arun, What do I do if I have I minor patch that I'd like to get out into 2.1, but where I don't want to introduce instability into that 2.1 branch if you are trying to make a beta release? For example, HADOOP-9651<https://issues.apache.org/jira/browse/HADOOP-9651> changes the exception that RawLocalFS throws when you try to create a file that already exists, so that it is consistent with HDFS.
If I wanted to get this into a 2.1-beta-2, what should the strategy be? Get it into trunk and then tag it as something to be considered for the followup beta? -steve On 4 June 2013 16:32, Arun C Murthy <a...@hortonworks.com> wrote: > Folks, > > The vast majority of of the planned features and API work is complete, > thanks to everyone who contributed! > > I've created a branch-2.1-beta branch from which I anticipate I can make > the first of our beta releases very shortly. > > For now the remaining work is to wrap up loose ends i.e. last minute api > work (e.g. YARN-759 showed up last night for consideration), bug-fixes > etc.; then run this through a battery of unit/system/integration tests and > do a final review before we ship. There is more work remaining on > documentation (e.g. HADOOP-9517) and I plan to personally focus on it this > week - obviously help reviewing docs is very welcome. > > Committers, from now, please please exercise your judgement on where you > commit. Typically, features should go into branch-2 with 2.3.0 as the > version on jira (fix-version 2.3.0 is ready). The expectation is that 2.2.0 > will be limited to content in branch-2.1-beta and we stick to stabilizing > it henceforth (I've deliberately not created 2.2.0 fix-version on jira yet). > > thanks, > Arun >
