hbase-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Allan Yang <allan...@apache.org>
Subject Re: [DISCUSS] No more release branches for 1.x, release from branch-1 directly
Date Sun, 09 Dec 2018 04:02:27 GMT
I think Andrew's way makes sense for branch-1, we can release 1.6,1.7 and
so on directly on branch-1. Since in branch-1, we will only have bug fixes.
If we want to apply this policy to branch-2, we'd be careful when new
functions check in, because all feature releases will include this function
if we only have a branch-2. But good news is that we only need to commit
our code to one branch, for now, sometimes I need to commit to four
branches(branch-2.0, branch-2.1, branch-2 and master). And for users, they
don't have to make difficult chose about which release line they need to
use. And they don't have to consider about compatibility when upgrading a
minor version. We make sure all the Incompatible changes are only commit to
master branch(for releasing 3.x).

Best Regards
Allan Yang


Stack <stack@duboce.net> 于2018年12月9日周日 上午7:35写道:

> On Fri, Dec 7, 2018 at 5:59 PM Andrew Purtell <apurtell@apache.org> wrote:
>
> > We could do that. Or we could simply renumber branch-1 to 1.6.x at that
> > time, e.g. 1.5.whatever-SNAPSHOT -> 1.6.0-SNAPSHOT. Every release has a
> tag
> > in rel/. It is possible at any time to check out from a release tag and
> > make a branch for an additional patch release for an old minor line. If
> we
> > need to do it, we can at that time, otherwise why proliferate branches
> and
> > make more work for committers? I think for branch-1 after moving from
> > 1.5.whatever to 1.6.0 any additional 1.5.x releases would be unlikely,
> and
> > going forward for 1.6, and so on. This same policy could work for
> branch-2.
> > We shouldn't be afraid to make new minors. Prior to 1.0.0 every release
> was
> > a minor release and patch releases were rare. I think we want to get back
> > to something more like that.
> >
> > It also makes sense to have a long term stable branch. That is currently
> > branch-1.2. If in the future we want it to be 1.5, then at that time it
> > makes sense to have a separate branch-1.5 for the LTS.
> >
> >
> Let's try it.
>
> Should be easy to do on branch-1 what with a single 'owner'.
>
> branch-2 would prove a more interesting experiment. Let branch-2 be where
> we cut 2.2.0 and 2.2.1, etc., from? (We need an RM for 2.2....)
>
> S
>
>
> >
> >
> > On Fri, Dec 7, 2018 at 5:54 PM 张铎(Duo Zhang) <palomino219@gmail.com>
> > wrote:
> >
> > > 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
> > > >
> > >
> >
> >
> > --
> > 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