Development Wiki

Release Process

From phpBB Development Wiki

Revision as of 11:44, 12 April 2013 by Naderman (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Release Types


Alpha releases may be made at any time before a beta release to make an intermediate state available to broader testing, for example after the addition of a major feature. This may reduce the number of issues found during the beta phase.


The first beta release marks the point at which a separate branch develop-<release-codename> (e.g. develop-olympus for 3.0) is created and new features go into develop by default. The release manager may still allow new features to be merged during the beta phase provided they are deemed important enough and are expected not to result in too many bugs.

Release Candidate

The first release candidate marks the feature freeze. From this point on only bug fixes may go into develop-<release-codename>.

Stable release

The first stable release results in a merge of develop-<release-codename> into master. Before this merge the old stable version is moved into master-<old-release-name> where it is maintained until EOL.

Detailed branching info is available on the Git Workflows section.


Release Manager

The release manager for a release branch is elected by all development team members with a simple majority. The release manager for a new release is determined when the previous release's develop branch is branched off of the main develop branch.

Merging Pull Requests

Every developer is allowed to merge pull requests but you should not merge these pull requests:

  • Do not merge pull requests where the author does not consider the pull request ready.
  • Do not merge pull requests you did not review or which you do not deem stable enough to be in a release as-is without further changes.
  • Do not merge pull requests which implement a new feature and are supposed to go into a stable branch. If the branch is in beta-mode, confirm with the release manager whether the new feature may be added first.
  • Do not merge pull requests you created yourself. After 3 weeks without comments after previous ones have been addressed the author may announce that they plan to merge their own patch without review by sending an email to the dev-team address. After another 2 weeks, so a total of 5 weeks the developer may merge the pull request himself.
  • Do not merge pull requests which have any unanswered questions or unaddressed comments
  • Do not merge pull requests which the release manager for the branch you are merging into (e.g. 3.0), or a release manager of a branch it would end up in (e.g. 3.1) or the development team leader has asked not to be merged

Blocking Tickets

Everybody can mark tickets as blockers. Developers should only downgrade tickets they reported themselves. The release manager for a branch makes the ultimate decision on whether a ticket is considered a blocker. If a developer disagrees with a ticket being marked a blocker this needs to be discussed with the release manager. The release manager is of course expected to take all opinions into account when making a decision.

If a merged feature results in multiple blockers which pose a problem for an upcoming release deadline the merge should be reverted and the feature will be postponed to the next release.


The release of Release Candidate 1 of a branch determines the date for the release of Beta 1 of the following branch, which takes place exactly one year later. Individual Beta and Release Candidate release should not last longer than 4 weeks. When a bug had to be fixed in a release candidate another release candidate is necessary before a stable release. Any release cannot take place until all blockers for that release have been resolved.