Squid Release Process
This process used by the Squid Developers as a guideline
in how and when new Squid releases are released:
- 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.
- When needed and there has been at least a fortnight from the last large
modification and at least one week from the last non-cosmetic patch
elease the next STABLE version. Repeat as neccesary.
$Id: release-process.html,v 1.1 2003/05/10 10:10:44 hno Exp $