Amend release process

Voting concerning ReactOS development paths. Read only for non-developers.
Post Reply

Should we amend the release process as specified below

Poll ended at Tue Nov 22, 2005 9:53 pm

Yes
13
100%
No
0
No votes
 
Total votes: 13

GvG
Posts: 499
Joined: Mon Nov 22, 2004 10:50 pm
Location: The Netherlands

Amend release process

Post by GvG »

Proposed changes to http://www.reactos.org/wiki/index.php/R ... t_Overview:

- change "Once the project coordinator signals that a release is to be made, dates are set for all three stages and the release process begins." to "Once the testing coordinator (in consultation with the release engineer) signals that a release is to be made, tentative dates are set for all three stages and the release process begins.".
- change "At the time of feature freeze, the first release candidate is produced by the release engineer." to "At the time of feature freeze, a release preview is produced by the release engineer.".
- change "Code freeze is the next stage of the release process." to "Code freeze, the next stage of the release process, is entered when the testing coordinator indicates that all blocker bugs in the release branch have been fixed.".
- change "At the time of code freeze, the second and final release candidate is produced by the release engineer." to "At the time of code freeze, a release candidate is produced by the release engineer.".
Royce3
Developer
Posts: 10
Joined: Tue Nov 30, 2004 10:40 pm
Location: Houston, Texas, USA

For the lazy among us...

Post by Royce3 »

Here is the text in whole as it will read, in case you want a sense of context:
ReactOS is a rapidly-developing project, and as such, it is our philosophy to make minor releases often. Each minor release includes additional support for applications and drivers, and also brings improvements in overall system stability.
Major releases are made when important usability and functionality milestones are reached. The most recent major release is 0.2, which brought the wonders of the Start button to the default ReactOS installation for the first time.

Release Process
The process of making a minor release involves three stages: feature freeze, code freeze, and release. Once the testing coordinator (in consultation with the release engineer) signals that a release is to be made, tentative dates are set for all three stages and the release process begins.
Feature freeze is the first phase of the release process. Prior to feature freeze, the main SVN repository is branched. While normal development continues on HEAD, the branch is closed to new feature development. During the feature freeze, bugfixes to any outstanding bugs are committed, and the code is cleaned up and made ready for release. Any nontrivial or destabilizing modifications to the branch must be discussed on the mailing list prior to committing. This also marks the beginning of the Quality Assurance process, where the system is tested for bugs and regressions relative to the previous release.
At the time of feature freeze, a release preview is produced by the release engineer.
Code freeze, the next stage of the release process, is entered when the testing coordinator indicates that all blocker bugs in the release branch have been fixed. During code freeze, the only allowed commits are bugfixes to release-blocking bugs. These fixes are generally discussed on the mailing list prior to committing a fix. The code freeze is primarily used as a time for the QA team to do a final sanity check of the release and for the release engineer to work out any last-minute build issues.
At the time of code freeze, a release candidate is produced by the release engineer.
Release occurs when the release engineer produces final packages of the system for distribution via reactos.com and sourceforge. Once a release is made, the release branch is closed from that point on to any sort of commit. At some point, when the project starts providing support for old releases (e.g. security fixes, compatibility updates, etc), patches will be made to the appropriate release branches.

Patch Policy

Remember, it is the responsibility of each developer to backport any branch fixes into the mainline code. Neither the release engineer nor the release coordinator (me) will do this job for you. Hopefully this is a simple task, as commits to the release branches should be small and rare.
Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests