On Friday 25 April 2003 17.24, Robert Collins wrote:
> I'd like to get 3.0 out to the users - the primary goal of 3.0 is
> understanding the impact of the C++ conversion. There are now no
> reproducible bugs in the 3.0 blocking list that aren't also 2.5
> bugs.
>
> So, while branching is orthogonal, I'd really really like us to
> mark 3.0 PRE1, or have a list of what is needed to make marking 3.0
> PRE1 sensible.
First there should be a feature freeze. When the feature freeze have
cooled down and settled PRE1 is in order.
Making a PRE release before a settled feature freeze of the version is
not in order. We did this in 2.5 and it was a big mistake which
seriously delayed the 2.5 release and probably also impaired the
quality of Squid-2.5.
> Oh, and I do have further things in the works, but I'd rather not
> be destabilising 3.0 after having tackled all the reported bugs...
My opinion on when to enter feature freeze: The feature freeze should
only be entered if it can be estimated that it really is a feature
freeze and that the feature freeze for the next following version is
at least 6-10 months away.
Regarding Squid-3: The code base has undergone rather intrusive
changes since the last STABLE (2.5), which is an indication that the
amount of required testing and bug fixing is likely to be rather
high. As a result of this it is extra important the code base is
properly feature freezed while testing. The changes was already large
before the switch to C++ and refactoring, and has only grown larger.
Regards
Henrik
Received on Fri Apr 25 2003 - 10:59:38 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:19:42 MST