hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From 张铎(Duo Zhang) <palomino...@gmail.com>
Subject Re: [DISCUSS] No more release branches for 1.x, release from branch-1 directly
Date Sat, 08 Dec 2018 01:47:34 GMT
If 1.5 is not the last minor release line, then how do we release 1.6? Make
a branch-1.5 and then start to release 1.6 from branch-1?

Andrew Purtell <apurtell@apache.org> 于2018年12月8日周六 上午9:36写道:

> Yeah, for branch-1 it is no longer a development branch. Every change is
> going to be maintenance related. No, I don't expect 1.5 to be the last
> minor release line for 1.x. Maybe? Maybe not. In theory we could treat
> branch-2 the same. Master is the only development branch. That is not my
> proposal, though. I'm only concerned with RM activities related to
> branch-1.
>
> On Fri, Dec 7, 2018 at 5:33 PM 张铎(Duo Zhang) <palomino219@gmail.com>
> wrote:
>
> > So the idea is that, if we have a newer major release line, we can
> release
> > the previous major releases directly from the 'developing' branch?
> >
> > I think for branch-1 it is fine, as we are not likely to backport any big
> > new feature to 1.x any more. And does this mean that 1.5 is the last
> minor
> > release line for 1.x?
> >
> > Stack <stack@duboce.net> 于2018年12月8日周六 上午4:15写道:
> >
> > > On Fri, Dec 7, 2018 at 11:36 AM Andrew Purtell <apurtell@apache.org>
> > > wrote:
> > >
> > > > Please be advised I plan to RM the next minor release from branch-1,
> > > 1.5.0,
> > > > in January of 2019. Once this is done we can continue making
> > maintenance
> > > > releases from branch-1.4 as needed but expect that not to be
> necessary
> > > > after a couple of months (or perhaps even immediately).
> > > >
> > > > I see no need to make a branch-1.5. As community resources continue
> to
> > > > shift away from branch-1 we need to conserve available attention. I
> > don't
> > > > see why we cannot release directly from branch-1. Certainly in the
> > > > beginning any branch-1.5 would be lock step with branch-1. No
> > distinction
> > > > in branch curation means no need for a new branch, at least
> initially.
> > > > Also, should a commit land in branch-1 that requires a new minor per
> > our
> > > > compatibility guidelines then I don't see why the next release from
> > > > branch-1 cannot a new minor (1.6.0, etc.) right there and then. We
> have
> > > > expressed intent to make more frequent minor releases anyhow.
> > > >
> > > > Related, I started a DISCUSS thread about EOL of branch-1.3.
> > > >
> > > > In my opinion the optimal future for branch-1, until all attention
> > moves
> > > > away from it, is continuing releases directly from branch-1 and
> perhaps
> > > > branch-1.2 (depends on Busbey's plans for it).
> > > >
> > > > If you would prefer we continue to make new branches for minor code
> > > lines,
> > > > I can do that for 1.5, no problem, but perhaps you will agree it is
> no
> > > > longer necessary.
> > > >
> > > >
> > > > Agree.
> > >
> > > I also like the idea of doing same thing for branch-2.
> > >
> > > 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message