So, chatting with Adrian today, and some friends, I have some thoughts about what precisely 3.0 should be.
I think 3.0 STABLE1 when release should be: * more functional than 2.6 STABLEX - there should be no regressions in functionality. * within 10-15% of the speed of 2.6 STABLEX. these two points are the primary things I can think of that will stop people adopting squid-3.0. And what we want is for developers to feel that 3.0 is a good bet for getting their code deployed. which means users deploying it :) Why the speed requirement? Because a slow 3.0 will turn people off it, and thats hard to recover from. "Last time I tried squid-3.x it was dog slow, blech." So heres a proposal: end of october, presuming all bugs are contained, we release 3.0 FC-1 - which stands for 'Feature Complete'. From now to then is just bugfixen etc. After october, every month or two - lets set a predictable window - we do FC-2, etc. We do *whatever it takes* architecturally and code wise to fix the release blocking bugs, and to get 3.0's speed sufficiently fast that we are all happy to call FC-??? STABLE-1. That means that large changes which are aimed at performance will be considered ok during the FC series. -Rob -- GPG key available at: <http://www.robertcollins.net/keys.txt>.
signature.asc
Description: This is a digitally signed message part