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.STABLE7Received on Thu Jul 03 2008 - 12:20:14 MDT
This archive was generated by hypermail 2.2.0 : Fri Jul 04 2008 - 12:00:03 MDT