Managing Releases

Who does it? Releases can be managed by the Release Lead of the project (if there is one) or the project lead.
How often? Weekly time-boxed release cycles are encouraged. Projects that have no end-user facing product may not have releases.
What to include in a release? Planning a release in advance is not practical if code contributions are intermittent and the available manpower for a given release cycle is not always predictable. In those cases the release can contains whatever new code that has been added since the previous release. However, major releases which are not backward compatible may need planning in advance.
Maintaining project velocity: It is important to keep resolving issues at regular intervals if the project were to keep moving forward at a reasonable pace. Recommendations:
- Shorten the lifecycle of ongoing PRs by aggressively reminding dev/reviewers to resume work when the PR progress becomes stagnant.
  - Project lead needs to periodically check the issue tracker for inactive PRs and remind the relevant persons to resume work.
  - If a PR is inactive even after a reminder, it can be closed (and the issue unassigned).
- Make issues smaller so that each can be resolved in a shorter time.
- Actively seek volunteers to do higher priority issues.

Configuration management for releases

Usually, a milestone is tied to a release. Use GitHub 'Milestones' and 'Releases' features to manage a release. In most cases, milestone name can be the version number of the release.
master branch should represent the latest version that is releasable. Normally, PRs are made against the master branch. If a new feature requires multiple PRs to merge before it is releasable, it should be developed in a long-lived feature branch first and merged to master only when it is releasable.
A release is signified by merging master into the release branch and tagging the commit with the version number. If the release is made using GitHub’s Release feature, it will create the tag automatically.
Release numbering must try to follow Semantic Versioning guidelines as far as possible. Format v{major}.{minor}.{patch} e.g. v5.1.2.
If a critical patch needs to be released as a hot fix (between regular releases), the patch is applied on the release branch first (i.e. the PR should be against the release branch). After the patch is released, the release branch is merged back to master.

Ensure the target commit on master is not broken.
Merge to release branch.
Create a release.
If PM (Project Manager) needs to do extra steps to 'deploy' the new version, create an issue on issue tracker and assign to PM.
Ensure all issues and PRs included in the release are tagged with the correct milestone and the correct assignees.
Extend the milestone of issues that slipped the current milestone and post a comment asking to finish by next milestone. If an issue is not making progress, close the PR and un-assign the issue.
If applicable, add/revise e. labels for the issues/PRs in the release. This may be required for contributors who need to track their effort (e.g. for payments or school credits). If the you are not sure of the effort, post a comment for the reviewer to add the labels.
Ensure all branches merged in the milestone have been deleted on GitHub.
Update (or create an issue for updating) contributor list in the project website.
Announce the release on relevant channels (e.g. slack, issue tracker).
Close the current milestone and create a new milestone for the next release.
Ensure all pending p.Urgent issues are assigned and scheduled for next milestone. Try to find volunteers for any p.High issues. You can require project lead’s assistance for this task.