hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Enis Söztutar <e...@apache.org>
Subject Thinking of branching for 1.0 by June 23
Date Tue, 10 Jun 2014 21:07:45 GMT

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

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.


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