hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Purtell <apurt...@apache.org>
Subject Re: The Renumbering (proposed)
Date Thu, 23 Apr 2015 19:03:50 GMT
That's fine but we still have unresolved problems:

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

We don't have a consensus on what to do about Hadoop 2.5/2.6. I proposed we
doc this like you say here before but got push back. So here I am talking
about renumbering as another path forward.

Whatever.. but let's decide this now and move on. Do HBASE-13339 in 1.1?
Three possibilities:
1. No, stay with 2.5
2. Yes, go to 2.6 and doc a warning about the issues that come in from
Hadoop
3. Yes, go to 2.6 and be semvar-pure by bumping 1.1 to 2.0.

And what about the changes in 1.0.1 that don't allow downgrade to 1.0.0 ?


On Thu, Apr 23, 2015 at 11:23 AM, Enis Söztutar <enis@apache.org> wrote:

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



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