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
signature.asc
Description: Detta är en digitalt signerad meddelandedel
