Prerequisites
A week(ish) before
- Validate autobuilds: green recently?
- Stop merging things
- Prepare and review release notes
- File an issue for results of patch testing (and rebasing)
- Manually test that popular patches apply and build, and perhaps even that their runtime behavior looks right
During
- 3 people
- 1 with a working PGP key and passphrase and a clean
git
checkout - 2 reviewers so release PRs can be merged immediately (currently these people)
- 1 with a working PGP key and passphrase and a clean
- 15 minutes for the autobuilds to run green
Shortly after
- 1 person with access to Open Build Service (currently these people)
1. Submit a PR for the version-bump changes
- Sync release notes with
CHANGES.md
- If we are still trying to manage change entries in two places
- Add new version to
CHANGES.md
, e.g. using thisgmake(1)
syntax:sed -i "1i - $(shell date +%Y%m%d) version: notqmail $(RELEASE_VERSION)" CHANGES.md
git commit -S -m "notqmail $(RELEASE_VERSION)" CHANGES.md
- etc. (this will be automated in
Makefile
by Dakon)
COPYRIGHT
with an updated claim (or lack thereof)- Add any new specific
-Werror
classes of warning that we've eradicated to all the autobuilds, if we haven't done so already (better to do it at the time)
2. Have the version-bump PR merged
- Requires 2 reviewers (as any PR)
3. Create the release tag
- Not from the release notes GUI, from the command line (in order to PGP-sign)
git tag -s notqmail-1.09
The first line of the tag description is the release name without the dash, i.e. notqmail 1.09
.
The rest of that description are the bullet points from the wiki page. It does not include the intermediate headlines and other comments.
4. Trivially re-rebase our patch branches
- On top of the new tag
5. Put release notes in GitHub
Choose the already created tag. Copy release notes from locally staged website:
cat html/releases/1.09/index.html \
| sed -e 's| href="\.\.\/\.\.\/| href="https://notqmail.org/|g' \
-e 's| href="\.\./| href="https://notqmail.org/releases/|g' \
| html2text --body-width 0 \
| sed -e '1d' \
| grep -v '^Last edited ' \
| grep -v '^Mirror: ' \
| pbcopy
Paste the release notes. Upload the 4 files (2 tarballs, 2 signatures). Publish release.
6. Create, PGP-sign, and upload tarballs to GitHub
RELEASE=1.08
git archive --prefix=notqmail-${RELEASE}/ -o notqmail-${RELEASE}.tar notqmail-${RELEASE}
gzip --best --keep notqmail-${RELEASE}.tar
xz --best notqmail-${RELEASE}.tar
gpg --detach-sign -a -o notqmail-${RELEASE}.tar.xz.sig notqmail-${RELEASE}.tar.xz
gpg --detach-sign -a -o notqmail-${RELEASE}.tar.gz.sig notqmail-${RELEASE}.tar.gz
Web-upload them here again
Maybe self-host copies of the release tarballs?
7. Push release notes to the website
Merge the local (or prod) branch to main
.
8. Update packages we control
- Open Build Service
- RPM builds:
notqmail.spec
(bump version number) - Debian builds:
notqmail.dsc
(bump version number) - for the
.tar.gz
link:_service
(update tarball link)
- RPM builds:
- Gentoo (
DerDakon
) - pkgsrc (
schmonz
)
9. Post everywhere about the new release
- Mailing lists:
- the qmail list
- maybe a new
users@
list at notqmail.org?
- Discussion forums:
- Social media
- Twitter @notqmail
- maybe a new Fediverse @notqmail@social.notqmail.org?
10. Review and adjust the roadmap
- Remember where we thought we wanted to go from here
- Add/change/defer/remove as needed