One of the major changes we made to 3.1 during its life cycle was the introduction of first-past-the-post feature additions instead of pre-planned and sealed roadmaps. Combined with a regular short release timeline instead of indeterminate long testing periods.
So why has 3.1 taken more beta releases than 3.0?
Unfortunately before that policy was implemented we did go down the old track a fair way and guaranteed that several features would make it into 3.1. One of these (SourceLayout) has proven to be a lot of slow work. (Not major re-writing thankfully).
The other new features code for 3.1 have been tested and stabilized between 3.1.0.1 and 3.1.0.6 and are happily in use on many production environments. But this last remaining feature still has a lot to go in and be tested for bugs. The result is 6 months delay on 3.1 and a handful of extra candidate releases, even some blockage of new stuff ready to go into 3.HEAD for the next release.
3.2 is starting off without this old legacy blocking problem, so it should be the first release to really gain the benefit of a much faster testing and release stages of production.
There are also a bunch of bugs which seem to be important but we are unable to track down and fix yet. Mostly holdovers from 3.0. The basic policy is to block release until all open bugs major or higher are closed. We might downgrade bugs to normal though if they are voted to be ignored.
While we wait for the last feature to stabilize some of us still try to work away at that list, additional volunteers are very welcome to speed things up. Meanwhile I would like some opinions please about the final stage for 3.1:
The Squid Web Proxy/Cache Blog 