Re: 3.0 branding - release plans - etc

sön 2006-09-10 klockan 21:52 +1000 skrev Robert Collins:

> I think 3.0 STABLE1 when release should be:
> * more functional than 2.6 STABLEX - there should be no regressions in
> functionality.

I disagree. It's more important that we get 3.0.STABLE out bugfree than
feature complete.
 
In my view the PRE4 release is feature complete, save for stuff which
can easily be forward ported (i.e. WCCP2, COSS).

Most of the stuff not yet forward ported isn't generally needed in the
average setup, and I don't see us being hurt significantly if these
isn't in the 3.0 release. If there is community interest in these
features then I am pretty sure we will see them getting forward ported
to Squid-3 when stable.

> * within 10-15% of the speed of 2.6 STABLEX.

If possible yes. Stability is more important at this time. But
performance is important indeed, especially for larger installations who
is also the most likely to sponsor developments..

> Why the speed requirement? Because a slow 3.0 will turn people off it,
> and thats hard to recover from. "Last time I tried squid-3.x it was dog
> slow, blech."

Yes, but I don't agree it's that slow. Sure 2.6 is faster, but 3 is not
dog slow in comparison.

> So heres a proposal: end of october, presuming all bugs are contained,
> we release 3.0 FC-1 - which stands for 'Feature Complete'. From now to
> then is just bugfixen etc.

I dislike introducing yet another release tag. The PREx releases is
already supposed to be feature complete but perhaps not bug free or
performing as well as STABLE. I think we just have to bite out own mess
and start following our own release plans and stop introducing new stuff
in 3.0.

Other than that yes, but with FC-1 being PRE5 and FC-2 being PRE6.

> We do *whatever it takes* architecturally and code wise to fix the
> release blocking bugs, and to get 3.0's speed sufficiently fast that we
> are all happy to call FC-??? STABLE-1.

Yes.

> That means that large changes which are aimed at performance will be
> considered ok during the FC series.

Yes.

If you ask me such changes is accepted even during a STABLE cycle, as
long as the change can be verified to

a) Not require/introduce new features (must)
b) Not destabilize the code (verified within reason)
c) We all agree that the performance gain is worth the internal API
changes.

Regards
Henrik