it's dangerous to change our default build to be something other than the oldest version we claim works because devs are less likely to notice when they make use of some new feature Hadoop added. It would help with what we ship in convenience packages, provided we do some reasonable testing of compatibility for newer client to older servers (or add a troubleshooting section reminder about how folks are supposed to replace the hadoop jars).
I guess we could add nightly tests that the old versions still work, but I'm currently skeptical that anyone will notice if such a check failed. I'm also in favor of conservative approach for branch-1. Ideally I'd like to wait for HBase 3.y to have our default Hadoop be 3.y. Without spiraling into a discussion about HBase major versions, I think we need to start shipping alpha HBase 3 builds once the stable pointer moves to a branch-2 based release. We've previously dropped support for Hadoop minor versions on a new HBase minor release. That's how 2.7 became the minimum version for 1.4.z and 1.5.z[1], there's a specific call out in the compatibility guidelines about how we can't be as conservative as we would prefer for something like Hadoop[2]. We also have talked about how we want to work towards dropping dependencies with impactful (open and no work around) CVEs[3]. If Hadoop doesn't keep doing 2.7 releases and we plan to do HBase 1.y releases for ~years, then it's probably a short window before we'll need to drop it. If that's unacceptable we should push back on the DISCUSS I linked at start of thread. Even if it's "HBase will get some contributors to show up in Hadoop and start running 2.7 releases" that would be better than e.g. us forking it here. [1]: "[DISCUSS] Branching for HBase 1.5 and Hadoop minimum version update (to 2.7)" https://s.apache.org/FS2m [2]: We have even stronger language in the guide where we say if Hadoop doesn't keep doing releases we drop the supported marker. http://hbase.apache.org/book.html#hbase.versioning.compat [3]: "[DISCUSS] Changing hadoop check versions in our hbase-personality?" https://s.apache.org/uQk2 On Fri, Jan 25, 2019 at 11:29 AM Andrew Purtell <[email protected]> wrote: > > I don't think we can drop support like that for minors per our compatibility > guidelines. I don't know how many run 2.7 or 2.8 in production. We use 2.7 so > for our own sake I'm -1 on this proposal. However we could change the default > 2.x version we build against to 2.9.2. Shall we discuss that ? > > I have no opinion on what should be the default build profile for branch-2. > For branch-1 it needs to stay at 2.x for now as I am not able to build it > successfully with the 3.x profile. I think it is also pretty unlikely someone > will opt to use our 1.x with Hadoop 3. We could ask. Even still, let's be > conservative with 1.x, please. > > > > On Jan 25, 2019, at 5:27 AM, 张铎(Duo Zhang) <[email protected]> wrote: > > > > I think we can drop the support of 2.7.x and 2.8.x when releasing 2.2.0 and > > 1.5.0? > > > > And is it the time to change our default building profile from hadoop2 to > > hadoop3? > > > > Andrew Purtell <[email protected]> 于2019年1月25日周五 上午11:22写道： > > > >> We could see what 2.9.2 looks like in terms of suitability and stability. > >> Is there any reason to look at 2.8 instead of jumping directly to 2.9? > >> > >> > >>> On Thu, Jan 24, 2019 at 1:33 PM Sean Busbey <[email protected]> wrote: > >>> > >>> heads up that the Apache Hadoop project is discussing marking their 2.7 > >>> release line as EOL: > >>> > >>> https://s.apache.org/Nm83 > >>> > >>> Hadoop 2.7.1+ is the most recent Hadoop release line to get the "(y)" > >>> marker in our Hadoop matrix for HBase branches-1. It's also the earliest > >>> Hadoop release line to get the same for our HBase branches-2. > >>> > >>> If folks want to weigh in on that discussion, now's the time. What, if > >>> anything, do we as a community want to do to prepare for when it > >> eventually > >>> happens? > >>> > >> > >> > >> -- > >> Best regards, > >> Andrew > >> > >> Words like orphans lost among the crosstalk, meaning torn from truth's > >> decrepit hands > >> - A23, Crosstalk > >>
