Henrik Nordstrom wrote:
On tor, 2008-07-03 at 21:21 +1200, Amos Jeffries wrote:
Well...
- these two in particular are binaries independent of the squid code.
They share only some portability objects.
squidclient got modified in squid-2 only because Squid gained new
features (basic HTTP/1.1 support). Not forward ported as Squid-3 does
not have this yet.
I'm looking at that now. squidclient binaries are used for testing other
servers as well as the squid proxy it bundled with, for example older
squid. So I guess I'm for porting the capabilities forward even if the
squid3 binary has no current use for them (yet).
I wasn't aware cachemgr had changes not yet in squid-3. What was
missing?
That was the easy one, just some windows support fixes, and cache
action: . I ported over earlier today.
- its bothersome to maintain two sets of duplicated code for an
indefinite period.
From now on just yell at anyone who commits changes to those tools in
Squid-2 without also making the change in Squid-3.
Thats a given. I was hoping for one of the two:
- adding a deprecation notice to the Squid-2 code file.
- bundling seperate and dropping the code from 2.7+ .
My future plans there involve more standards compliance, which may make
things harder for people if there are two code versions to look at. The
upcoming compat changes from 3.2+ may also impact as non-portable back
to Squid-2.
- 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.
Good.
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.
Most people run only one or the other, bundled together.
So its time to consider their deprecation in the Squid-2 CVS before any
further changes get done.
Why?
It's not a big burden to keep them syncronized.
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.
The tools partially depend on Squid libraries. I don't think it's worth
the effort to try separating out these tools.
Additionally it won't really solve the problem, just move it around a
little..
Better to spend effort on the "squid-2 forward port changesets
repository" we talked about before, enabling us to keep close track of
which squid-2 changesets should be forwardported.
The more I think about that the bigger the job seems.
I want to talk about that on IRC soon...
Regards
Henrik
Amos
--
Please use Squid 2.7.STABLE3 or 3.0.STABLE7
