On Tue, 2005-11-01 at 17:42 +0100, Serassio Guido wrote: > My opinion is that currently the development work on Squid 3.0 is > something harder than on 2.5/2.6 for some reasons:
It depends on the kind of work, I think. Little fixes are often easier to do in Squid2. Large projects (e.g., making Squid HTTP/1.1 compliant) would be easier to do in Squid3. IMO, serious Squid2 development is a masochistic activity. The same can be said about current Squid3. Its current code is insane in many aspects, often worse than the corresponding Squid2 code! However, there is reasonable hope that Squid3 code can be cleaned up. I do not have such hope for Squid2. > So, if the development of Squid 3 will continue as the latest year, > really I'm not so sure that we will ever have a STABLE 3.0 with a > support and maintenance comparable to 2.5. Agreed. We are probably approaching a "last chance" state for Squid3. It cannot stay in limbo for much longer. There is current interest and some funding to clean it up and make it stable, but more is needed. Unfortunately, defrosting Squid2 hurts Squid3 efforts I am involved with. YMMV. > For me, the consolidation of existing 2.5 working patches and > enhancements into a 2.6 release is the only way to avoid things like this: > http://www.squid-cache.org/mail-archive/squid-dev/200510/0181.html. I disagree. To avoid the above, we have only two options: - Break 2 promises: Defrost Squid2. Officially kill Squid3. - Keep 2 promises: Keep Squid2 frozen. Make Squid3 stable ASAP. Opening up Squid2 for enhancements _and_ hoping to get Squid3 stable in the same time is likely to just dry up funding for Squid3. Again, I have no violent objections to committing a very small set of existing essential and widely deployed patches to Squid2 (as long as we promise not to do it again!). If something is not currently 100% finished, tested, and widely deployed, then I do not think it should be committed to Squid2.6. Alex.
