On Wed, May 12, 2010 at 11:29 AM, Todd Lipcon <t...@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. > Yes. >> >> 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. Agreed. St.Ack
