Re: Squid-3.0 release planning

Suggested adjusted process:

 * Finalise the list of to-be-included features. Features outside this
list is not accepted for HEAD from this point

 * When a reasonable subset of the to-be-included features exists and
is believed to work, release DEVEL-X and optionally announce to
squid-users. Repeat as neccesary when there is significant progress
in getting closer to the to-be-included feature set..

 * When all features exists and is believed to work, release PRE1 and
announce to squid-users. At this point Release Notes should exists
(included in testing), and ChangeLog will reflect any changes done,
small as large.

 * When there has been a fortnight with no critical bugs, branch the
new version and reopen HEAD for new developments.

 * Give each PRE release a fortnight for bugs, and when we go for a
fortnight with no new bugs, release STABLE1.

 * From STABLE1 any changes should have a corresponding bugzilla
entry, and be documented with description and patch on the
bugs/patches page of the release.

Regards
Henrik
Received on Tue May 06 2003 - 17:41:40 MDT