Release Process (starting AF3 2.12 in summer 2017)



There are six roles: the release manager (RELMGR), the release engineer (RELENG),
the developer (DEV), the tester (TEST), the reviewer (REV), 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.

REVS are doing the code review.

USERS are the target audience for the tool.

While TEST and REV for a feature can be one person, neither role can be combined with DEV.

Release Candidates

There are four release candidates before the release version is built and shipped:

Release Candidate Purpose
RC0 beta-version: all features to be included in the release are provided by their leading developers. List of plugins is fixed.
RC1 feature-complete version: all features from RC0 are implemented.
RC2 tested, bug-fixed version: all features from RC1 have been tested and bugs have been fixed. Code is YELLOW.
RC3 documented, reviewed, and announced version: all features from RC2 have been documented and the website announcement is prepared. Code is GREEN.
REL release version: the release deliverables are built, download page and website are updated, and the release is announced on the mailing list.


RC Weeks to release Weeks from last RC Comment Scheduled date for AF3 Release 2.12 Code State
RC0 10 --- Initial RC Aug, 4th, 2017 RED
RC1 6 4 Feature Freeze and code rated YELLOW Sep, 1st, 2017 YELLOW
Delay week due to MODELs conference Sep, 15th 2017
RC2 2 4 Test completed and bug fixed Oct, 13th 2017 YELLOW
RC3 1 1 Documented and code rated GREEN Oct, 20th 2017 GREEN
REL 0 1 Release Date Nov, 10th 2017 GREEN

Release Candidate 0 Details

RC0 collects all features to be included in the upcoming release.
It is not meant to be distributed for testing, but rather managed
in the issue tracker. The features need not be implemented fully
or tested completely. However, the set of all plugins contributing
to the release must be fixed for RC0.

RELMGR collects all features under the RC0 version in the issue
tracker and assigns it to the DEVS in charge. RELMGR also
assigns a tester for each feature by adding her or him to the
list of watchers of the issue.

RELENG adjusts the build server setup to include all plugins,
which are determined to participate from this point onwards.

DEVS, TESTS and REVS update their installation to be in
line with the set of plugins, once this set is fixed during the
developer meeting. Since new plugins are usually already introduced
outside the release hot phase, no big changes are expected here.

Actions: During the following four weeks all features MUST
reach the state of readiness for testing. Documentation should
be provided as good as possible. Code MUST be cleaned and
rated YELLOW. Tests and test procedures MUST be defined.

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. Changes made within this period MUST keep the code
in YELLOW rating state.

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.

REVS and DEVS complete the code review until all the code
is rated GREEN.

Actions: During the following week the documentation and
the code review MUST be completed.

Release Candidate 3 Details

RC3 is shipped with a finalized documentation and the code
base is rated GREEN. It is also 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

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.