I'm going to do a monthly cadence with 1.4. It's a bit delayed getting off the ground sadly because I need to address Francis' feedback and otherwise get RSGroups in before cutting the first RC, and I was recently out for two weeks on vacation. Soon, though.
Or, we can start spinning minors off of branch-1 with the same cadence: 1.4.0, then 1.5.0, 1.6.0. Monthly or bi-monthly. Versions are cheap. Releasing minors would keep branch-1 in a good state and give us more flexibility for making changes (at the possible detriment of downstreamers we might break with LP changes, so hopefully we can be better about that). If we go this route I Will probably also maintain patch versions for 1.4 because our production will move up on it for a while. We will have to convince ourselves the issues with locking introduced in 1.3 have settled before moving the stable pointer beyond 1.2. > On Sep 18, 2017, at 9:07 PM, Nick Dimiduk <ndimi...@apache.org> wrote: > > Reviving this thread. I know our interest is around branch-2 right now, but > I think we are close to an actionable resolution here. > > I'm a fan of Andrew's proposal of stabilizing our branch-1 for maintenance > releases, getting away from all the minors if we can. Do we have a quorum > of folks able and willing to do that work? Seems like it would center > around the 1.4 release. > > If branch-1.1 retires in the next 2-6 months, are we happy with branch-1.2, > branch-1.3, or branch-1.4 carrying on the monthly cadence? Do we have a > strong need to continue 1.x once 2.x is out? Are we calling 1.2 the LTS > with quarterly patch releases, 1.3 aborted on arrival, and pushing folks > onto 2.x? Do we want to settle on quarterly or bi-annual minor releases and > only patch monthly or as necessary in between? > > Thanks, > Nick > >> On Wed, Aug 9, 2017 at 8:00 AM, Mike Drob <md...@apache.org> wrote: >> >> One thing that we need to be super careful about after releasing 2.0 is >> that we don't accidentally introduce any incompatible changes. It's much >> harder to reason about forwards compatibility than backwards compatibility >> in my experience. So even though a hypothetical 1.5 would be released after >> 2.0, users would still have the expectation that a 1.5->2.0 upgrade would >> be smooth (unless we explicitly message that it isn't but that is a whole >> new set of problems). >> >> Also, to clarify some context here -- what is the difference between an LTS >> branch and a Stable branch? Don't they convey the same thing to users? As a >> relative newcomer, I feel like I missed an earlier conversation about this. >> >> Mike >> >>> On Tue, Aug 8, 2017 at 10:45 PM, Phil Yang <ud1...@gmail.com> wrote: >>> >>> Another option is no 1.5/branch-1 any more. What new features we are >> going >>> to have in HBase 1.5 (if it will be released)? Backporting from branch-2 >> to >>> branch-1 is not easy, so maybe we will not have any big feature in >> branch-1 >>> after releasing 1.4. And if we release 1.5 after releasing 2.0, it may >>> confuse users. So IMO we can focus on branch-2 for new features. >>> >>> I think it will be good if we have fixed logic for EOL branches, for >>> example(just an example, can discuss): >>> 1:Release a final version and EOL 1.x after we think 1.x+1 is stable. >>> 2:Cut off new 1.x+2 branch after 1.x+1 is stable, don't cut too early. >>> >>> Then we will not need discussing each time for each branch EOL and we >> will >>> have a fixed number of maintaining branches. >>> >>> Thanks, >>> Phil >>> >>> >>> 2017-08-09 1:44 GMT+08:00 Andrew Purtell <apurt...@apache.org>: >>> >>>> Well you are not wrong that branching was premature, it turns out. But >>> I'll >>>> roll with it... >>>> >>>> >>>> On Tue, Aug 8, 2017 at 10:43 AM, Zach York < >> zyork.contribut...@gmail.com >>>> >>>> wrote: >>>> >>>>>> I made branch-1.4 a few weeks ago only. >>>>> >>>>> Whoops, sorry for that! For some reason I thought I had seen it >> months >>>> ago. >>>>> >>>>> On Tue, Aug 8, 2017 at 10:40 AM, Andrew Purtell <apurt...@apache.org >>> >>>>> wrote: >>>>> >>>>>> +1 from me on making 1.1 our LTS. Either 1.1 or 1.2 are >> candidates. I >>>>> think >>>>>> 1.1 has the edge because it lacks locking changes introduced into >>> 1.2, >>>>> just >>>>>> like 1.2 lacks locking changes introduced in 1.3 - the latter of >>> which >>>>> has >>>>>> had far reaching consequences, and the former not an insignificant >>>> change >>>>>> either. >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Aug 8, 2017 at 10:31 AM, Nick Dimiduk <ndimi...@gmail.com> >>>>> wrote: >>>>>> >>>>>>> On Tue, Aug 8, 2017 at 9:15 AM Mike Drob <md...@apache.org> >> wrote: >>>>>>> >>>>>>>>> The discussion also brought up the notion of an LTS release >>> line. >>>>> I'm >>>>>>> not >>>>>>>>> sure how this jives with the more fequent minors, but would >>>> require >>>>>>> some >>>>>>>>> branch that's so stable that an RM can effectively spin >>> releases >>>>>> blind. >>>>>>>> >>>>>>>> Seems to me like this branch would necessarily need to be very >>>>>>>> backport-light? Only the top of the highest priority issues >> would >>>> be >>>>>>>> backportable to it, no? >>>>>>> >>>>>>> >>>>>>> The LTS is as 1.1 is today -- bug fixes only. The difference here >>> is >>>>> we'd >>>>>>> "formally" recognize the LTS designation somehow, perhaps with a >>>>> symlink >>>>>>> marker as we do for the "stable" designation. >>>>>>> >>>>>>> On Tue, Aug 8, 2017 at 11:09 AM, Nick Dimiduk < >> ndimi...@apache.org >>>> >>>>>> wrote: >>>>>>>> >>>>>>>>> Last time we DISCUSSed EOL of 1.1 was back in November. At >> that >>>>>> time, a >>>>>>>>> litany of issues were raised re: 1.2. Have those concerns >> been >>>>>>> addressed? >>>>>>>>> It seems to me that making this one the last release is too >>>> abrupt >>>>> to >>>>>>>> folks >>>>>>>>> tracking Apache. Would be better to give some notice. >>>>>>>>> >>>>>>>>> Had a nice hallway conversation a couple months back (at >>>>> PhoenixCon, >>>>>> as >>>>>>>> it >>>>>>>>> happens; they feel the pain as well) about our branch >>> situation. >>>>> I'll >>>>>>> let >>>>>>>>> the others chime in with more details, but the gist as I >> recall >>>> is >>>>>> that >>>>>>>> we >>>>>>>>> should be doing more frequent minor releases with fewer patch >>>>>> releases. >>>>>>>>> This pushes stabilization efforts closer to master and also >>>> imposes >>>>>>> more >>>>>>>>> strict stability requirements on big new features before they >>> can >>>>> be >>>>>>>> merged >>>>>>>>> off the feature branch. >>>>>>>>> >>>>>>>>> The discussion also brought up the notion of an LTS release >>> line. >>>>> I'm >>>>>>> not >>>>>>>>> sure how this jives with the more fequent minors, but would >>>> require >>>>>>> some >>>>>>>>> branch that's so stable that an RM can effectively spin >>> releases >>>>>> blind. >>>>>>>>> >>>>>>>>> On Tue, Aug 8, 2017 at 12:14 AM Stack <st...@duboce.net> >>> wrote: >>>>>>>>> >>>>>>>>>> (This came up during dev meeting in Shenzhen) We are >> running >>>> too >>>>>> many >>>>>>>>>> branches and/or when applying patches, we do not do a good >>> job >>>>>>>>> backporting >>>>>>>>>> to all active branches, especially fixes. >>>>>>>>>> >>>>>>>>>> We have master, branch-2, branch-1, branch-1.4, branch-1.3, >>>>>>> branch-1.2, >>>>>>>>> and >>>>>>>>>> branch-1.1 active currently. If a dirty bug fix, the >> applier >>> is >>>>>>>>> backporting >>>>>>>>>> to 7 branches. It takes a while applying to all especially >> if >>>> the >>>>>>>>> backport >>>>>>>>>> doesn't go in clean. I suppose the RM could monitor all >>>> upstream >>>>> of >>>>>>>> them >>>>>>>>>> and then pull wanted patches back (we could do that too) >> but >>>>> seems >>>>>>>> like a >>>>>>>>>> burden on an RMer. >>>>>>>>>> >>>>>>>>>> We should EOL a few? >>>>>>>>>> >>>>>>>>>> Nick is on branch-1.1 release at the moment. Perhaps this >>> could >>>>> be >>>>>>> the >>>>>>>>> last >>>>>>>>>> off branch-1.1. >>>>>>>>>> >>>>>>>>>> 1.2 hosts our current stable release though 1.3 is out. How >>>> about >>>>>> we >>>>>>>> cut >>>>>>>>> a >>>>>>>>>> release off 1.3, call it stable, and then EOL 1.2 after >>> another >>>>>>> release >>>>>>>>> or >>>>>>>>>> so? >>>>>>>>>> >>>>>>>>>> What you all think? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> S >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Best regards, >>>>>> Andrew >>>>>> >>>>>> Words like orphans lost among the crosstalk, meaning torn from >>> truth's >>>>>> decrepit hands >>>>>> - A23, Crosstalk >>>>>> >>>>> >>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Andrew >>>> >>>> Words like orphans lost among the crosstalk, meaning torn from truth's >>>> decrepit hands >>>> - A23, Crosstalk >>>> >>> >>
