> > If Ryan can do the port of 2248 to trunk this week, then I'm +1 on > > merging branch into trunk. I would then think that in a 2-3 week > > timeframe we would cut a new branch off of trunk and stabilize it. > > > > 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.
The idea would be to do this once new features will no longer be allowed and anything but bug/stability fixes would not be allowed. Either we branch off trunk once we're ready to make that call, or we hold off on commits to trunk. I just recommend branching so new stuff can still be developed against trunk. In the past we've not been very strict about keeping trunk stable and I think this has been to our advantage. Obviously as we get bigger we need to stabilize more but I'm not in the camp of wanting an always releasable trunk. An always working trunk is good. Do you think we should move to a feature branch model if we keep trunk releasable? We should definitely try to prevent split work between branches/trunk, but this is really the first time it's happened in HBase land. I think chasing Hadoop appends and the lack of Hadoop releases has a lot to do with how we got here. > > 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. Maybe I wasn't clear. My vote is to do the disruptive stuff immediately with the move to trunk, well before we would cut a branch off trunk for release. Branching would happen once the release manager decides it's time to cut the branch. For anything besides bug fixes, it would be up to the RM to cherry pick anything from trunk for the branch. It's also not such a big deal to apply to branch+trunk once they are close together... right now some logistical stuff like directory structures and some refactoring makes it more of a pain than normal. JG
