Planning phase

The Qt Release Manager must make sure a detailed release schedule is planned, approved and publicly visible early enough, at least 3 months before the actual feature freeze.

The Qt Release Manager produces an initial release schedule and sends it for comment to the development mailing list (development@qt-project.org). There must be about a week for comments before the initial schedule is approved in a Qt Release Team IRC meeting. After approval The Qt Release Manager is responsible for publishing the schedule in the public release wiki.

Development phase

The development phase for a new minor release (e.g. 5.12) starts when the previous minor release is branched from the dev` branch. All new features and new submodules must be implemented during the development phase and integrated in the release on the ``dev branch. All new features and submodules need to fulfill the Feature Freeze criteria before the official Feature Freeze date and the Module Maintainer is responsible for making sure this happens early enough. Any new feature or module which does not meet these criteria must be removed from dev well before Feature Freeze.

The release team will produce binary snapshots from the dev branch as early as possible. Those are called "Dev snapshots" in the online installer UI.

Approximately a week before the official Feature Freeze we start soft branching from dev to the feature branch (e.g. 5.12). Branching is finalized at the same time as Feature Freeze takes effect.

The development phase ends when Feature Freeze takes effect.

Alpha phase

The alpha phase means the release is feature-complete and we are asking for feedback on the API and new functionality. The alpha phase starts at Feature Freeze. The first alpha release is done immediately after Feature Freeze is in effect and qt5.git integration has succeeded in the feature branch.

The release team is responsible for producing regular alpha releases for testing during the alpha phase. The target is to produce a new alpha n+1 release every week or two during the alpha phase.

An alpha release only commits to deliver source. Binaries are also made available in each alpha release as far as possible. Missing binaries don't block an alpha release.

An API review for the release is started immediately after Feature Freeze. The alpha phase ends when this API review is completed.

Beta phase

The beta phase means implementation is complete and we are asking for feedback on the quality of the implementation, seeking bugs and regressions to be fixed.

In the beta phase, all changes coming in should focus on improving the quality of the release.

The first beta release is published immediately after the first successful qt5.git integration after the API review completes. Beta releases include prebuilt binaries. The release team is responsible for producing regular beta releases for testing during the beta phase. The target is to produce a new beta n+1 release every week or two during the beta phase.

During the beta phase, the Release Manager is responsible for announcing String Freeze for the release. Changes to translatable strings for the release are no longer allowed after String Freeze. A week before the official String Freeze, the Release Manager is responsible for announcing a soft String Freeze which is actually an advance warning of the coming official String Freeze.

Every module maintainer is responsible for making sure all 3rd party components are updated for the release by the end of the beta phase. The Release Manager will send a reminder about this to the development mailing list.

During the beta phase, the Release Manager keeps a list of release blocker bugs. This list is a filter, in the Qt project's bug-tracking system, that contains

1. all open P0 bugs affecting that release
2. all open bugs having that release in "Fix Version(s)"

The beta phase ends with branching from the feature branch to a new release branch (e.g. from 5.12 to 5.12.0).

Release Phase

In the release phase, the target is to finalize the quality of the release. Bug fixing is done in the release branch (e.g. 5.12.0) and putting in 'nice-to-have' fixes is no longer allowed. Fixes must be mostly for bugs in the blocker list; in addition to this, fixes for really severe P1 issues can also be taken in. As an exception to this, documentation updates can be taken in until the RC is released.

The release team will produce initial change files for each module in the release immediately after branching the release branch from the feature branch. After that, module maintainers are responsible for finalizing those promptly [1].

The first Release Candidate (RC) is done immediately after all blockers from the release blocker list are fixed and the module changes files are ready. If new release blockers are found, fixes for them will be taken in and a new RC will be released. That continues until the RC is good enough. By default the minimum time reserved for testing the first RC is 2 weeks; but the time between the last RC and its Final Release can be shorter.

The release phase ends when the final release is out.

References