On Sun, 24 Mar 2013, Amos Jeffries wrote:
We have 5 new features in 3.HEAD now and it seems to be stable enough for
public use.
See http://wiki.squid-cache.org/Squid-3.4 for the list of what I am
classifying as a new feature.
*** I am contemplating branching 3.4 into a beta series in the coming weeks
***
That will mean probably June or July for a stable release.
Hi Amos,
Thank you for managing the release cycle.
Are there any objections?
No objections from me, although I am concerned that, based on the wiki
page you referenced, trunk may have no significant new features to
warrant differentiating it from v3.3 now, except perhaps for Store ID.
This may explain why the trunk is about as stable as v3.3 :-). On the
other hand, if branching v3.4 now will not increase support and
porting overheads (e.g., because we will stop supporting v3.2??), then
we should "release early, release often", I guess.
FWIW, there are several significant features that are nearly ready for
Squid Project review. Roughly ordered from most important/ready to
least, these features include:
1. Large Rock. The code works in lab tests and is nearly ready for
submission. The primary delay is that I want to bundle it with the
Store API polishing I promised, but that polishing does not affect
admins and can wait if we are in a hurry.
2. Basic collapsed forwarding. The code works in non-SMP mode, but I
need to finish SMP support before I can submit the patch for Squid
Project review. This may take a few weeks.
3. Secure tunnels to cache peers. The code works in lab tests, but we
need to remove duplication of forward.cc pieces before I can recommend
it for Squid Project review.
4. Shared SSL sessions among SMP workers. This performance
optimization is important to folks accelerating secure sites using SMP
Squid. The code works in lab tests, but we need to remove some
duplication of StoreMap pieces before I can recommend it for Squid
Project review.
5. Support for quoted strings in ACLs and other squid.conf options.
The code needs some minor polishing.
Again, I do not object to v3.4 branching before the above features are
posted for review. If you want to see at least some of them in v3.4
(and do not want to port them later) then waiting 4-6 weeks may help.
HTH,
Alex.
