Release Process (AF3 2.16)
==========================
Overview
--------
### Roles
There are five roles: the release manager (**RELMGR**), the release
engineer (**RELENG**),
the developer (**DEV**), the tester (**TEST**), and the user (**USER**).
**RELMGR** is driving and coordinating the release process during the
two-month hot phase.
**RELENG** is in charge of the build server, provides the release
candidate versions to
the developers, and publishes the release version to the website.
**DEVS** are providing the implementation and documentation of features
to be included
in the upcoming release.
**TESTS** are testing the features for correctness and usability.
**USERS** are the target audience for the tool.
Neither role can be combined with **DEV**.
### Release Candidates
There are three release candidates before the release version is built
and shipped.
RC1 |
feature-complete version: all features for the release are implemented. |
|
RC2 |
tested, bug-fixed version: all features from RC1 have been tested and bugs have been fixed. |
|
RC3 |
documented, reviewed, and announced version: all features from RC2 have been documented and the website announcement is prepared. |
|
REL |
release version: the [[New_Release_Check-List |
release deliverables are built]], download page and website are updated, and the release is announced on the mailing list. |
### Schedule
RC1 |
2 |
feature-complete: Merge freeze |
Sep, 30 2019 |
RC2 |
1 |
tested, bug-fixed version; Binary RC |
Oct, 8th 2019 |
RC3 |
1 |
documented; release announcement prepared; Binary RC |
Oct, 11th 2019 |
REL |
0 |
Release Date |
Oct, 15th 2019 |
Release Candidate 1 Details
---------------------------
**RC1** includes all features implemented and prepared for testing.
New features *MUST NOT* be introduced after RC1 (“Feature Freeze”).
This means no new features are to be committed to the repository.
Any such changes should be kept either in a branch (\_not advised
for Subversion\_) or as a patch file on a separate server (e.g.
mail server).
**RELENG** builds the RC1 version for distribution to **TESTS**.
**RELMGR** reviews the code ratings and assigns **REVS** for each
plugin. There should be an issue in the tracker for each plugin.
**TESTS** execute the tests for the features and issues assigned
to them and report the results back to the **DEVS** using the
corresponding issue.
**REVS** start reviewing the code in coordination with **DEVS**.
**DEVS** react to bugs reported by **TESTS** and code improvements
suggested by **REVS**. Furthermore, they tackle bugs that are
already in the tracker system.
***Actions***: During the following two weeks the tests *MUST*
be carried out and the results and/or bugfixes *MUST* be
applied.
Release Candidate 2 Details
---------------------------
**RC2** is the tested and bugfixed version, which is made
accessible to the user community for beta-testing.
**RELENG** builds the RC2 version and makes it accessible to
**USERS** for beta-testing.
**RELMGR** checks if testing phase was completed and all bug
issues have been closed. If some are still open, immediate
action should be enforced, possibly relocating resources.
**RELMGR** also checks the state of the review process and
assigns additional resources if some parts look like being
left behind.
**RELMGR** starts to compile the release notes.
**DEVS** and **TESTS** react to issues reported by beta-testers
and start finalizing the documentation. **DEVS** provide input
for their features to the release note compilation in the
issue tracker.
Release Candidate 3 Details
---------------------------
**RC3** is shipped with a finalized documentation and is
made accessible to the users for beta-testing.
**RELENG** builds the RC3 version and makes it accessible to
**USERS** for beta-testing.
**RELMGR** checks if the documentation, code review, and the
release notes compilation was completed.
***Actions***: No actions should be necessary during the silent
week, unless something very serious needs immediate attention.
Release Version Details
-----------------------
**REL** is no different from RC3 unless some serious last minute
hot fixes have to be applied.
**RELENG** builds the release version and makes it accessible
to **USERS**, updates the website and publishes the release
notes.
**RELMGR** configures the issue tracker for the next release by
adding the versions for RC0 to RC3 and REL. All code review
issues are moved to the next RC3 version. All versions of the
current release are closed.
***Actions***: Feature freeze is lifted and the normal procedure
for commits is in place again.