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 <[email protected]> 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)
