Henrik Nordstrom wrote:
On tor, 2008-07-03 at 23:39 +1200, Amos Jeffries wrote:
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.
The bigger reason NOT to drop the tools from Squid-2 imho..
The changes I'm thinking of will pull the compat out into its own
independent lib to supply both tools and squid with portability separately.
I disagree on it being a reason to keep the old ones, the non-port bit
is wont compile against -2 source. Which only means the compat source
needs bundling with the tools, which is the case anyway.
A tool built from the -3 repository is completely capable of
communicating and using -2 regardless of the libraries its built against.
The main goal is forward, not backward.
Yes. So why continue to maintain a small piece of 99% independent code
simply because it's in the 'back' bundle?
I do not mind at all seeing changes in the Squid-3 version of the tools
not getting backported to Squid-2.
As I see it there is two choices:
a) Split the tools out completely, make them live their own life outside
of the main Squid repository.
b) Keep as-is.
If we can't find a good way ahead, I'll settle for this. But don't like
the possibilities it opens up.
My favorite is 'b'. The goal is after all that Squid-2 should slow down
as Squid-3 picks up speed.
REgards
Henrik
Amos
--
Please use Squid 2.7.STABLE3 or 3.0.STABLE7
