Re: Branching 3.0?

On Saturday 26 April 2003 14.25, Robert Collins wrote:

> I take your point, but I don't think it's a feasible heuristic...
> We have so many pending features now, I don't think we'll ever have
> a period where we can feature freeze, if we use that criteria: By
> the time the features are in, there will be more in the pipeline...

Sorry, I do not see the point.

> I'd like to propose a different approach, which is to push for
> shorter development-release cycles, with less aggregation of
> changes in each release, combined with an increasingly capable
> self-test suite.

Going for a release cycle less than 6 months is probably not practical
for Squid for many reasons. It takes about 1 year for a new release
to become mainstream.

> Having said that, I've no problem with tentatively slating 3.1
> feature freeze for nov...jan.

So where is the problem then? ;-)

What I am requesting is

* Squid-3.0 is feature frozen before branched

* Once feature frozen, it should remain so unless there is very good
reasons to break the feature freeze. If it can immediately be seen
that this most likely won't be the case then the feature freeze is
not valid.

* The feature freeze of Squid-3.0 is verified and settled before
3.0.PRE1 is released.

* There should be no less than 6-10 months between new releases to
allow for a decent STABLE release cycle.

Note: A feature freeze does not necessarily imply that all features
are working or even implemented.

Regards
Henrik
Received on Sat Apr 26 2003 - 19:30:51 MDT