I would recommend upgrading the Squid cluster because it's run on a very significantly old version of the software, lacks several years worth of general patches and maintenance, and because it's not THAT big a deal. As I mentioned earlier in thread, I spent several years running Squid (at the time, 3.0-stablevarious and 3.1 beta tests) at a large site, and it didn't take that much time and effort despite working actively with Amos and others on what turned out to be an uninitialized buffer problem for over a year and having to compile, tune, and seriously test all the versions from 3.0-STABLE3 through ... 19, it looks like. It was perhaps 20% of my total work for about 3 years, and would have been far less had it not been for the one persistent bug (going from the prior 2.6 squids to 3.0 took about 3 months of me 1/4 time-ish). Performance was noticeably better with 3.0 vs 2.6 and 2.7.
Well, by all means, add our patches in to the newer version, and provide a source package.
Avoidance of obsolete version software rot is a key operations technique. My current main commercial consulting customer has 5 years-past-end-of-support key enterprise infrastructure software that they don't even quite know how to upgrade, it's so old now. Don't let your versions get that old...
Yes, 2.7 is still getting necessary Squid project patches, latest to STABLE9 in March 2010, but still. It's old 8-)
Our plan is to eventually move away from squid and to varnish. Upgrading squid really isn't amazingly high on our priority list right now.
Respectfully,
Ryan Lane