hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Hsieh <...@cloudera.com>
Subject Re: Thinking of branching for 1.0 by June 23
Date Tue, 10 Jun 2014 21:26:17 GMT
+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