Maintainer Guidelines¶
Tags & Branches¶
At the point where no more functionality will be added to a release, a new branch gets created. All bug fixes pushed to the master branch should be cherry-picked to the respective stable branches and vice versa.
. .
/|\ /|\
| |
| |
3.6.-1 / <--- "quodlibet-3.5" branch
|_____/ .
| /|\
| |
| 3.4.1 <--- "release-3.4.1" tag
| |
| 3.4.0.-1
| |
| 3.4 <--- "release-3.4.0" tag
| |
3.5.-1 /
|______/ <--- "quodlibet-3.4" branch
|
| <--- "master" branch
3.4.-1
|
/|\
Release Checklist¶
New Stable branch:
- git checkout -b quodlibet-x.y
- git commit -m “new stable branch
- git push
- git checkout master
- Update version to (X, Y + 1, -1)
- git commit -m “version bump”
New Stable release:
- git checkout quodlibet-x.y
- Cherry pick stuff from master
- Update NEWS
- git commit -m “update NEWS”
- setup.py distcheck
- Update version to (X, Y, Z) in const.py
- Update version to (X, Y, Z) in appdata.xml.in
- git commit -m “release prep”
- git tag release-x.y.z
- git push origin release-x.y.z
- Update version to (X, Y, Z, -1)
- git commit -m “version bump”
- Cherry pick NEWS commit onto master
- Create Windows builds / tarballs / macOS dmgs
- Create checksums / signature, attach everything to the github tag
- Update release_db/make.py; run ./release_db/update.sh
- Update stable PPAs (ubuntu/debian/OBS)
- Update the flathub repo
- Write release mail