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