hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Yu <yuzhih...@gmail.com>
Subject Re: Thinking of branching for 1.0 by June 23
Date Tue, 10 Jun 2014 21:29:36 GMT
+1 with approach B

Cheers


On Tue, Jun 10, 2014 at 2:26 PM, Jonathan Hsieh <jon@cloudera.com> wrote:

> +1 for approach B/#2. and +1 for 0.99 versions.
>
> Jon.
>
>
> On Tue, Jun 10, 2014 at 2:07 PM, Enis Söztutar <enis@apache.org> wrote:
>
> > Hi,
> >
> > As per previous threads, I am planning to branch out 1.0 at Jun 23, Mon.
> It
> > will include the changes committed as of that date. HBASE-10070 merge
> > should be completed as well. We can have the meta-based assignment as
> well.
> > Branching now, versus after we do 0.99.0 release gives us the chance to
> > stabilize the branch for the release.
> >
> > I am aiming for having a 0.99.0RC0 out by end of June, do one or more
> > 0.99.x releases in July and having 1.0.0RC0 by Aug or so.
> >
> > I think for branching we can do two approaches:
> >
> > a) create a branch named "1.0". Change the master branch version to be
> > 1.1-SNAPSHOT. This implies that master branch cannot have any breaking
> > changes until we branch for 2.0. If we do not need it, this will be
> > simpler.
> >
> > Something like this:
> > master (1.1-SNAPSHOT)
> > |
> > | 1.0 (1.0-SNAPSHOT)
> > | |
> > | x (1.0.0)
> > | |
> > | x (0.99.1)
> > | |
> > | x (0.99.0)
> > | |
> > |/
> >
> > b) create a branch named "branch-1". Change the master branch version to
> be
> > 2.0-SNAPSHOT. This implies that all patches that are intended for 1.x
> > series will go to branch-1, and all 1.x releases will be branched off of
> > branch-1. Also branch-1.0 will be branched from branch-1.
> >
> > Something like this:
> >
> > master (2.0-SNAPSHOT)
> > |
> > | branch-1 (1.1-SNAPSHOT)
> > | |
> > | | branch-1.0 (1.0.1-SNAPSHOT)
> > | | |
> > | | x (1.0.0)
> > | | |
> > | |/
> > | x (0.99.1)
> > | |
> > | x (0.99.0)
> > | |
> > |/
> >
> > In both of these plans, 0.99.xRCs will come out of the branch for 1.
> >
> > After we branched, we will only accept patches relevant to 1.0 release.
> In
> > that respect, it won't be a feature freeze, but we will selectively
> > backport features that we think would be needed for 1.0. Main candidates
> > are the subtasks / linked issues in
> > https://issues.apache.org/jira/browse/HBASE-10856. Some of the issues
> > there
> > still lacks some love, so I am not sure whether they will be done in
> time.
> > If not, we do not have any choice but to kick them out by the time 1.0
> > comes. Everything still goes to master first.
> >
> > Let me know what you guys think. Any alternate proposals? Which one we
> > should do? I am more in favor of b) which will be the most flexible route
> > to having true semantic versioning for the cost of added branch
> complexity.
> > a) should be fine as well if we are fine with lazy branching for 2.0.
> >
> > Enis
> >
>
>
>
> --
> // Jonathan Hsieh (shay)
> // HBase Tech Lead, Software Engineer, Cloudera
> // jon@cloudera.com // @jmhsieh
>

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