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

Reply via email to