On Mon, Nov 07, 2005, Henrik Nordstrom wrote: > But my experience is that very few customers are willing to wait for > Squid-3 to become stable, instead demanding that the feature is also > developed for Squid-2.5 for production use "now" and in addition also to > Squid-3 to be future safe. > > I also see that Squid is quite rapidly loosing it's presence on the market > in favor for our friend Apache for reverse proxies and a number of > commercial closed vendors for Internet proxies, in large due to Squid-2.5 > starting to become quite behind in both functionality and performance > unless one is willing to spend a lot of time on patching (a situation not > to far from that of qmail I would say except that we at least have all the > major bugs fixed...)
I agree with Henrik here. We need something that works, and works now. A lot of the proposed 2.6 changes should go into squid-3 rather easily, including my IO stuff. Heck, I'd like to do some work on COSS which could be easily ported to work with squid-3 but I can't guarantee that squid-3 is stable/predictable enough to know whether its squid-3, or my COSS code. My place o'work won't let me run squid-3 on the test servers until its released -STABLE. So I believe that releasing a stable 2.6, with all the features to make it attractive to current users, will go a long way in keeping /squid/ alive. Its a stable platform to try out new ideas against. I don't think that releasing it with some definite performance and feature improvements will reduce the squid-3 work done to date. But then, as I've noted, I'm byast: I really, really want to throw my stuff into squid-2.6 so I can attempt some really noticeable performance increases. They'll still be applicable to squid-3.0, and I think my IO tidyup will reduce the complexity of the squid-3 network IO code. Adrian
