Re: squid-3 vs 2.6

From: Reuben Farrelly <reuben-squid-development@dont-contact.us>
Date: Sun, 25 Jun 2006 02:11:40 +1200

On 25/06/2006 1:23 a.m., Henrik Nordstrom wrote:
>> Would everyone on this list support the following:
>>
>> 1. No more 2.x development - new features must be against 3.x
>
> Sorry, until Squid-3.0.STABLE is in such shape that it can run in
> production without the admins having to worry all night this won't
> happen. Even if we all promise. Simple fact of life..
>
> But as soon as we get Squid-3 in production quality shape this should
> apply I think.

A clear upgrade path would be good to have and communicate, but without releases
ready to go it's a bit tricky, as you just pointed out.

With 3 or 4 branches on the go, there is a lot of potential for users to get
confused by this and people to run code with possibly wrong expectations about
what support they can expect.

>> 2. Release 3.0.STABLE as quickly as possible (stability is priority,
>> still may lack features from 2.6)
>
> Yes.
>
>> 3. Release 3.1 soon after that (feature complete, 2.6 is obsoleted)
>
> To be honest I think the two will coexists for some time. But Squid-3
> will win over time.

I also think we should decide at some point how and for how much longer we are
going to support 2.5 and 2.6 in the absence of sponsorship, and announce a
roadmap soon so that users have lots of warning of what is coming up. We don't
want to end up with 2.5, 2.6 and 3.0 in a stable cycle with 3.1 in development
all at the same time at the end of this year ;)

Therefore I suggest that..

1. For Squid-2.5, we announce soon (possibly when we release 2.6) a date on the
End-Of-Life of maybe 1 November (4 months away). After that, then no fixes, no
repairs for any bugs, and no effort made to hunt down problems in 2.5 code (ie
"reproduce against 2.6 or 3.0"). There are far too many users running this code
to make it too soon, but the sooner we can recommend, get people to test, and
release 2.6 the sooner we can officially obsolete 2.5 and have one less codebase
to maintain.
The upgrade path from 2.5 is ideally Squid-3.0 if we have it ready by November
(and I hope we do), or failing that, Squid-2.6. Squid-2.6 will suit some users
better as 3.0 won't have all the features of 2.6 anyway. But that way at least
Squid-2.5 will be officially dead by the end of the year.

and

2. For Squid-2.6, a tentative date on the lifespan of Squid-2.6 as being
supported for 8-12 months after 2.6-STABLE1 release date which takes it through
to March-July next year (maybe a bit longer if it's not much work to maintain
and/or it flushes out bugs that we can also forward port easily in 3.0).
Support for only 6 months it probably a bit too short, but the times are a bit
debatable. Hopefully by then we will have forward ported everything and 3.1
will be well and truly ready to go (if not already released).

Once Squid-3 is out it should be the primary recommended version for use
especially with any new installations and we should make sure that the wiki and
website appropriately pushes people in that direction.

reuben
Received on Sat Jun 24 2006 - 08:26:44 MDT

This archive was generated by hypermail pre-2.1.9 : Fri Jun 30 2006 - 12:00:02 MDT