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 >
