On 03/07/2008, at 3:20 PM, Amos Jeffries wrote:
I've just completed bringing Squid-3 cachemgr.cgi up to full feature
parity and backward compatibility with 2.6/2.7.
Next on my list is the few fixes in squidclient which have not made it
over yet.
How do the rest of you feel about formally deprecating/obsoleting the
tools bundled with Squid-2?
possibly 'freezing' their code as they reach this point of full-parity?
Any comments on how it should be done.
Mark Nottingham wrote:
> Why?
>
Well...
- these two in particular are binaries independent of the squid code.
They share only some portability objects.
- its bothersome to maintain two sets of duplicated code for an
indefinite period.
- when I'm done with them now, the Squid-3 code is either identical
(excluding whitespace formatting and comments) to the Squid-2-HEAD code.
Or at least have all the bug fixes and improvements made in 2.6/2.7 to
date underneath their Squid-3 fixes and polish.
One of the project goals is to form a clear upgrade path from 2.x to
3.x. These two tools have in my view now achieved that clear upgrade
path, with full backwardly compatible code in the Squid-3 VCS.
So its time to consider their deprecation in the Squid-2 CVS before any
further changes get done.
I've given this some further thought since my initial hurried email and
I think it would be easy enough for us to bundle the code for them
separately as a squid-tools package which happens to be built from the
Squid-3 bzr if we need to.
Amos
--
Please use Squid 2.7.STABLE3 or 3.0.STABLE7
