Why not cut the 2.0 branch now?
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. john On 12/15/2009 7:17 AM, Leif Hedstrom wrote: > On 12/09/2009 05:15 PM, John Plevyak wrote: >> >> I would like to ask for a vote on whether or not to commit the cache >> partition size patch (+1, -1, 0). > > I think we're gonna have to "call" this vote, and with only 2 +1 and > one -1, we need to postpone this checkin until the 2.0 "branch" is > cut (and we open up trunk again for new features). In the mean time, > my suggestion would be that you create a branch in SVN (call it > "TS-46" or "cache_partition" or something like that), and commit it > there. This way, people can easily make builds testing it, and we can > later just merge it back into trunk. > > Cheers, > > -- leif
