Release Process

= Release Types =

Alpha
Alpha releases are made to preview functionality in an upcoming major release. The purpose of alpha releases is to begin broader testing of the new features, and to involve a wider audience in such testing. Alpha releases are targeted at modification/extension authors and more experienced board administrators.

Beta
The first beta release marks the point at which a separate branch develop- (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-.

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

Detailed branching info is available on the Git Workflows section.

= Scheduling = 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 must not take place until all blockers for that release have been resolved. Other issues assigned to the release can be moved to the next appropriate release.

After the first stable release of a branch the old branch will be maintained for at least one more year.

phpBB 3.1 does not have a Beta 1 release date and will be published as soon as all blockers are resolved and the extension subsystem (extensions, migrations) has been sufficiently tested to ensure phpBB is equipped for more regular releases without breaking all customizations made by users.

= Contributions =

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 phpbb.com address. After another 2 weeks, so a total of 5 weeks the developer may merge the pull request himself. If a release manager or the team leader asks the pull request be held back, you must not merge your own pull request even after the 5 weeks expired.
 * 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.