Those that have been paying attention will have noticed that Squid-4 beta cycle has been going on for a very, very long time. A whole year now in fact. There are several reasons for this.
* The ecosystem that Squid is deployed into has a somewhat mixed situation in regards to C++11.
Even 5 years after it was standardized compiler support is still not readily available in some popular OS distributions. In particular there are a large number of people clinging to the outdated but still supported RHEL 6 and its derived family of OS which do not easily provide recent versions of GCC. So we are procrastinating on the deprecation of Squid-3.5 to give more people a chance to move on. The clock is ticking though.
* We had a lack of early adopters testing the early versions of Squid-4.
So bugs that only show up in real usage have been very slow to be found. We don’t make a new version start its beta cycle until the developers are reasonably sure that its stable enough to be used. The beta process is supposed to be just a confirmaton of that. Indeed a year ago 4.x looked like it had no bugs at all. Which is kind of suspicious, but not impossible. As the betas progressed though the bug reports started rolling in. It is somewhat a testament to how our modern build systems are catching out minor and trivial bugs that these tester reported issues have largely all been difficult to resolve.
* We are experimenting with a new management process for Squid releases.
Previously Squid-5 would have been branched for development and Squid-4 starting to stagnate, er, become “stable”. This time though we have delayed the branching and instead kept Squid-4 as main development branch for minor changes while the beta cycle goes on. That has made it a little more volatile than most of the Squid-3 series betas.
All up, we are down to the last few major bugs to be resolved in the new code. Progress on those is slow but steady. So Squid-4 production “stable” release should be not to far ahead on the calendar.
The Squid Web Proxy/Cache Blog 