hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <andrew.purt...@gmail.com>
Subject Re: The Renumbering (proposed)
Date Fri, 24 Apr 2015 16:31:38 GMT
On the "Clarifying..." thread we have decided to be working toward semver at this time so the
proposal here is not needed. :-)


> On Apr 23, 2015, at 10:18 AM, Andrew Purtell <apurtell@apache.org> wrote:
> 
> 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)

Mime
  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message