hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stack <st...@duboce.net>
Subject Re: Merging 0.20 BRANCH and TRUNK WAS -> Re: JIRAs committed on trunk but not branch (take 2)
Date Thu, 13 May 2010 06:10:40 GMT
On Wed, May 12, 2010 at 11:29 AM, Todd Lipcon <todd@cloudera.com> wrote:
> I am sort of +0 on cutting a new branch at that point. What I would
> prefer to see is moving towards an "always releasable trunk" model, in
> that stuff doesn't go into trunk unless it's reasonably usable. Large
> changes should be done in feature branches before getting committed.
> Otherwise, my fear is that we're just going to end up in this
> situation again in 6 months.

I'm grand w/ keeping TRUNK stable as we go forward w/ big changes done
on branches.  For sure TRUNK should never again be predicated on
another project's shipping a critical dependency.

I'm also down though w/ branching once features are frozen as a way to
cordon off code while its being stabilizing in prep. for posting a
release candidate.  Only bug fixes in branches from here on out!

>> I would vote for making that branch 0.90.  I would also vote for doing anything
else big/disruptive/compatibility breaking at the same time we all move onto trunk and kill
the branch.  For example, the switch to org.apache.hbase should happen now rather than later.
 Since trunk also includes some versioning stuff in the RPC, we'll be able to add stuff to
the API moving forward without breaking client compatibility, so it seems like breaking it
all now is a good idea.  We may not need to break it again for whatever comes after 0.90.
 Also remember, the old APIs are already ripped out of trunk.
> The big changes that we do for this new branch should happen before
> the branch is cut, not after - otherwise we'll have the same problem
> where the two branches are so far apart that merges are impossible.


>> Anyone with major objections to any of this?  We should move to a vote soon.
>> Also, I think we should adopt the practice of having a Release Manager for when we
cut the branch off trunk.
> +1, I like the idea of RM.



View raw message