On HBASE-13339 (starting at https://issues.apache.org/jira/browse/HBASE-13339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14507527#comment-14507527) there's an emerging consensus that we should renumber 1.1 as 2.0, so we can move up to Hadoop 2.6.0 there without risk of breaking any semver promises, and, therefore, master branch from 2.0 to 3.0.
Given the concerns expressed recently about API additions with respect to semvar in the 1.0.1 RCs (see the thread on dev@ titled "Clarifying interface evolution freedom in patch releases"), if we do renumber 1.1 to 2.0 I think this gives us an opportunity to resolve any concerns about 1.0.1 by renumbering it as 1.1.0. How this might work tactically is: git checkout master <mvn command to renumber to the 3.0 series> git add `find . -name pom.xml` ; git commit -m "..." ; git push ... git checkout branch-1 git branch -m branch-2 # rename branch-1 to branch-2 <mvn command to renumber to the 2.0 series> git add `find . -name pom.xml` ; git commit -m "..." ; git push ... git checkout branch-1.1 git branch -m branch-2.0 # rename branch-1.1 to branch-2.0 <mvn command to renumber to the 2.0.0 series> git add `find . -name pom.xml` ; git commit -m "..." ; git push ... git checkout branch-1.0 git checkout -b branch-1 # create new branch-1 from branch-1.0 <mvn command to renumber to the 1.1 series> git add `find . -name pom.xml` ; git commit -m "..." ; git push ... This leaves us with a "branch-1.0" that has commits of concern where API additions have been made that wouldn't allow transparent downgrade. We'd revert or amend those: git checkout branch-1.0 git revert .. ; git commit or <edit some files> git add ... ; git commit -m"Amend ..." ; git push ... Thoughts? -- Best regards, - Andy Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
