Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@hbase.apache.org
Received-SPF: softfail (athena.apache.org: transitioning domain of
 saint.ack@gmail.com does not designate 54.164.171.186 as permitted sender)
MIME-Version: 1.0
Sender: saint.ack@gmail.com
In-Reply-To: 
 <CA+RK=_C6OJi=y_4XTMHJZ2YUSbMpD9tvVHNk_P9ZMi_CahU1jA@mail.gmail.com>
References: 
 <CA+RK=_C6OJi=y_4XTMHJZ2YUSbMpD9tvVHNk_P9ZMi_CahU1jA@mail.gmail.com>
Date: Thu, 23 Apr 2015 11:07:00 -0700
Message-ID: 
 <CADcMMgHhnusJMNEG_APCy7HuAC6S1=5AY5-vCfwB_w3=B5F1Ag@mail.gmail.com>
Subject: Re: The Renumbering (proposed)
From: Stack <stack@duboce.net>
To: HBase Dev List <dev@hbase.apache.org>
Content-Type: multipart/alternative; boundary=001a1147e8e86520b00514682567

--001a1147e8e86520b00514682567
Content-Type: text/plain; charset=UTF-8

On Thu, 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.
>


The presence of a 2.x so soon after 1.0 will cause 1.x to wither away (as
0.96 was overshadowed by 0.98) and will confuse our users since it is ~98%
1.0.0.

Are the hadoop 2.5.x/2.6.x incompats just a few transitive includes brought
in by hadoop 2.6? Can we not release-note/doc our way a semvar pass because
our brothers upstream are less puritan than us? Heck, lets 'blame' them!

If not, lets not touch the hadoop in hbase-1.x:

+ No one runs on the version bundled with HBase (our first instruction is
to replace what HBase bundles).
+ If a feature requires a later version of hadoop than we bundle, remove
the feature or only have it come alive if a later version of hadoop is
running under us (with appropriate doc).
+ If our current hadoop has a bad bug (HDFS-7004), we talk it up and have
folks upgrade (if nothing to upgrade too, lets help make it happen).
+ If a hadoop beyond what we ship, update our matrix after running some
tests (noting if anything needs change).

Why did we not find HDFS-7004 previous? I've been running cluster tests but
I've been up on hadoop 2.7 branch so have not come across HDFS-7004 (my
bad). When others are testing they are running on random apache hadoop
version or random CDH, HDP, etc. The notion that the hadoop we bundle must
'work' beyond passing unit tests and being able to run standalone is a
strait-jacket we should not put on.

St.Ack


> 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)
>

--001a1147e8e86520b00514682567--