I'm in support of this. The current scheme is confusing, and as you mentioned, is making the backport strategy less clear. It reminds me of the branch-2.8 vs. branch-2 (destined for 2.9) days when various fixes would make it into one or the other.
One other action item would be to do a quick verification that the new branch-2.10 (current branch-2) has any fixes which were put into the current branch-2.10. It should be a superset of the changes that went into the two branches. Thanks for the proposal, Jonathan! Erik On Thu, Nov 14, 2019 at 11:26 PM Jonathan Hung <jyhung2...@gmail.com> wrote: > Some other additional items we would need: > > - Mark all fix-versions in YARN/HDFS/MAPREDUCE/HADOOP from 2.11.0 to > 2.10.1 > - Remove 2.11.0 as a version in these projects > > > Jonathan Hung > > > On Thu, Nov 14, 2019 at 6:51 PM Jonathan Hung <jyhung2...@gmail.com> > wrote: > > > Hi folks, > > > > Given the release of 2.10.0, and the fact that it's intended to be a > > bridge release to Hadoop 3.x [1], I'm proposing we make 2.10.x the last > > minor release line in branch-2. Currently, the main issue is that there's > > many fixes going into branch-2 (the theoretical 2.11.0) that's not going > > into branch-2.10 (which will become 2.10.1), so the fixes in branch-2 > will > > likely never see the light of day unless they are backported to > branch-2.10. > > > > To do this, I propose we: > > > > - Delete branch-2.10 > > - Rename branch-2 to branch-2.10 > > - Set version in the new branch-2.10 to 2.10.1-SNAPSHOT > > > > This way we get all the current branch-2 fixes into the 2.10.x release > > line. Then the commit chain will look like: trunk -> branch-3.2 -> > > branch-3.1 -> branch-2.10 -> branch-2.9 -> branch-2.8 > > > > Thoughts? > > > > Jonathan Hung > > > > [1] > https://www.mail-archive.com/yarn-dev@hadoop.apache.org/msg29479.html > > >
