On Sat, 2005-10-22 at 19:37 +0200, Henrik Nordstrom wrote:
> There was also some talk about what to do with the Squid-2 code base.
> There is very a large list of completed features developed for Squid-2.5
> over the years and then ported and merged to Squid-3, but in reality
> production environments are all running the Squid-2.5 versions with
> different amounts of extra patches today. Not surprising given the fact
> that Squid-2.5 has been feature frozen for 3 years now.
If we are talking about applying a few existing stable conflict-free
Squid3-ported patches to Squid2 and calling that Squid2.6, then it may
be a good idea.
If we are talking about opening up Squid2 for adding "a very large list"
of features that used to be coded (or perhaps just prototyped) at some
point in time after the Squid2 freeze, then would not it be a better to
make Squid3 stable instead? Especially if you think that all those
features were ported to Squid3?
FWIW, when we try to get companies sponsor Squid3 work, the Squid2
feature-freeze status is the single most important factor. If that
status changes (whether officially or by public perception), it would be
a lot more difficult to get Squid3 work sponsored (not to imply that it
is easy now!).
Would it be possible to limit 2.6 changes to a select few, widely used,
well-tested, Squid3-ported features unrelated to performance and similar
optimizations?
Thank you,
Alex.
Received on Wed Oct 26 2005 - 16:27:33 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Nov 01 2005 - 12:00:07 MST