hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enis Söztutar <e...@apache.org>
Subject Re: The Renumbering (proposed)
Date Thu, 23 Apr 2015 18:23:43 GMT
>
>
>
> 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.
>

We should not forget that we are doing semver for the benefit of users. I
agree completely that
having 2.0 only 3-4 months after 1.0 is a major cause of confusion. We
would have a very hard
time to explain why we have 1.0 and 2.0. And all the issues from upgrade
from 0.98 to 1.0,
0.98 to 2.0, 1.0 to 2.0 etc will be a mess to document.


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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message