Definitely there is value in starting this so trunk doesn't sink into a difficult to release state. Alpha releases seem fine if you want to make them. This assumes you'll have at least a small amount of bandwidth to run tests and triage any issues, though, or else any effort would be better spent completing the work needed to move the stable pointer to 2.x. Just my random advice.
On Thu, Apr 25, 2019 at 7:55 AM Sean Busbey <[email protected]> wrote: > Hi folks! > > We're about a year from when HBase 2.0.0 went GA. I'd like to start > cutting alpha releases of 3.0.0 off of the master branch soon. > (expressly I do not want to create another branch, so for now anything > landing in master would be "in" for 3.0.0. hence the "alpha" > designation.) > > I was going to wait for one of the HBase 2 releases to get the stable > label. But lately I don't have a good sense of if that will happen > within a month or within six months, so I'm leaning away from waiting. > > I personally don't have a particular feature I'm trying to get out the > door. I just think we're at risk of another waiting-too-long for a > major release and want to get started on the work of quantifying > what's changed and figuring out how downstream projects are impacted. > I find that all much easier to do when there's a release artifact to > reference. > > I'm happy to just cut alpha releases until someone shows up with a > specific feature need. At that point we can come up with criteria for > entering and exiting beta releases. > > What do folks plan to work on getting ready that needs happen in a > major release? > -- Best regards, Andrew Words like orphans lost among the crosstalk, meaning torn from truth's decrepit hands - A23, Crosstalk
