On 12/15/2009 09:48 AM, John Plevyak wrote:
Why not cut the 2.0 branch now?
We're still waiting to land changes that were made in the Y! internal tree after we moved the source to ASF. We need those into the 2.0 branch, I'm pretty sure. We're also still discussing the changes for the "remap" APIs, to decide what we should do. After we cut the 2.0 branch, I'd assume we do bug-fixes only (and no new features) on that branch (kinda defeats the purpose of branching otherwise).
If the consensus is to branch now instead, and merge all these changes both into trunk and branch, we can do that (but my vote would be -1).
The existing codebase has some serious issues in the event scheduling system (for example large cache miss latencies, an issue I am submitting) along with performance problems handling medium size objects (more than 100k) in addition to the limits handing large objects. The API should be updated to support large objects as well. Taken as a whole these issues restrict the applications that the current codebase can be applied to, so if we are not going to address them all in 2.0 we might as well fork 2.0 now and restrict ourselves to bugs with usability and packaging in 2.0 and move main development to a new 2.X branch.
All that sounds good. I think we generally want to have "trunk" be new development, and we branch when we have a feature set that we think is "good" to branch on. I don't think trunk is quite there yet, since we're waiting to land a few things that we do want in 2.0 (as I mentioned above).
The reason I suggested making a "dev" branch for your cache partition changes was to let people test it right now. I don't have an ETA when we think trunk weill be ready to branch for 2.0 (assuming we stick to that methodology, and not do feature development on multiple branches).
Cheers, -- Leif
