Re: Squid-3.0 release planning

Some more tweaks:
* only start announcing when all user visible features are in and
*thought* to work: saves confusion.
* Release notes maintained from here on in - we have the basis already
in CVS - it's easier to keep it up to date, than to scan cvs logs
post-fact.

On Wed, 2003-05-07 at 09:41, Henrik Nordstrom wrote:
Suggested adjusted process:

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

* When the to-be-included user visible features exists and
is believed to work, release DEVEL-X and announce to
squid-users. Repeat as neccesary when there is significant progress
in getting rid of any giant bugs or oversights. At this point Release
Notes should exists
(included in testing), and ChangeLog will reflect any changes done,
small as large.

(I.E. overlapping requests may not be in at this point, but it's not
user visible - so doesn't delay announce of DEVEL)

* When no giant bugs are found for a fortnight, release PRE1 and
announce to squid-users. (At this point, we should get some early
adopters providing feedback)

* 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.

Cheers,
Rob

-- 
GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.