squid-3 vs 2.6

To follow up on some discussion seen on IRC.

featurewise it's relatively small stuff in 2.6 not in squid-3 yet. Some
of the things in 2.6 is more polished than in Squid-3 however, but these
differences should even out as Squid-3 QA progresses.

Missing features:

  - collapsed forwarding

  - WCCPv2

  - TPROXY

  - Connection pinning for relaying of Microsoft Integrated Auth.

  - ETag

  - Follow X-Forwarded-For

  - anything else?

Polishing:

  - Parts of the SSL cleanup. Main requirements being the pending bits
in the comm code, or refactoring solving this I/O operation independence
differently.

  - Reasonable read defer management.

  - COSS ng (or whatever to call what Adrian is doing to COSS). Some of
this actually fits better in Squid-3 with it's re-factored I/O
framework.

  - >2GB objects

  - HTCP updates

  - Many small bugfixes here and there in the new features common to
both trees.

  - probably a bit more

What happened to Squid-3 was that there was a release plan which was
nice and cool about a quick translation to C++ but feature wise
identical to 2.5. Then re-factoring was done a bit too far bringing a
slew of stability issues combined with a lot of new features added (the
two goes hand in hand, and was unavoidable at the time) resulting in a
considerably higher divergence from Squid-2 than planned, and around
this Robert (the main architect of the Squid-3 rewrite) got another job
requiring a change in priorities on his part. As a result for a long
time we had a Squid-3 tree which was in the mid of very many changes all
over the place, and the architect behind these changes buzy elsewhere..
Also, some stuff was let into the tree a bit premature like the quite
far going Range processing changes. With this situation there was not
much choice but to continue developing in Squid-2 and forward porting
the results to Squid-3 with the hope that the results will be useful the
day Squid-3 shapes up..

I have a feeling we now finally have the tree Squid-3 in a quite
consistent state, but a lot of bug fixing naturally remains. Most of the
Squid-2 bugs remaining in "port to Squid-3" status should however be
taken mostly as hints there may be problems in these areas of Squid-3.
In reality many of these likely doesn't exists in Squid-3, either from
being fixed independently or re-factoring where the failing code has
been rewritten eliminating the problem that way.. The majority of the
expected Squid-3 bugs is likely unique to Squid-3, and not Squid-2
patches not yet forward ported..

To survive the main focus for Squid-3 MUST be to get the tree stable.
Until we reach that point the community will continue to diverge as most
customers still demands production ready deployment.

I don't see it as a big problem if there is some features in Squid-2.6
which maybe will not be seen in Squid-3.0, that's why there is a
Squid-3.1 release. The Squid-3 tree already have sufficient amount of
new unique features to draw attention. Customers who are in need of any
such 2.6 only feature will have the choice of running 2.6 and missing
the new features only available in Squid-3, or make sure the feature
they need is forward ported proper closing the gap from 2.6 to 3.

The 2.6 release is actually about focusing the community again. It's
better to have two focused releases, than the past situation of nearly
every installation (including binary vendor distributions) unique with
different combinations of patches applied to the feature-wise ancient
2.5 release. Myself have been running something which maybe resembles
70% of 2.6, and it's hard to find any larger installation running a
stock 2.5 release. This has been very evident on the squid-users
discussions in the last years which increasingly has been about applying
different feature patches to 2.5, which is not a good sign for the
health of the project.

Regards
Henrik