Our release process is a giant checklist living in a gitlab template which, while nice and organized and cool, could be partially automated. The things we've enumerated include:
translation hash updates
rbm.conf
version
incrementals
release date
dependency checking and config updating for:
noscript
ublock
mullvad extension
openssl
zlib
zstd
tor
go
manual
tor-browser
geckoview
firefox-android
improved changelog generation (eg include esr/geckoview updates, etc)
handle updates when passed manually to the script
wire the script to the release preparation script and automate it even more!
qa + release emails
website MR
blog MR
21 of 24 checklist items completed
· Edited
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
We update the allowed-addons.json for Android. This file happened to have URLs and sha256 already.
Or, if we don't update it, we can use the same REST API used to generate it.
mullvad extension
openssl
zlib
These are all on GitHub.
Earlier, I've discovered that on GitHub you can add .atom at the end of the release page URL, and you'll get a machine readable version (Atom feeds).
The version is usually embedded somehow in the git tag, that we could get by parsing the release entry id (tag:github.com,2008:Repository/$repositoryId/$tag) or the link (https://github.com/$developer/$repo/releases/tag/$tag).
I think this should help with cases such as the withdrawn OpenSSL 1.1.1r (for which, if I understand correctly, the GitHub release was correctly deleted).
Also, we could add Zstd to the list (which is also on GitHub).
But it's a little bit problematic at the moment, because of Windows (still, we could probably do it).
manual
Already automated .
Maybe we could make it even easier.
tor-browser
geckoview
git tag is probably the safest option here.
A problem might be that early alphas might not be based on an ESR, but it should be easy enough to solve (also, alphas are updated just after the rebase).
improved changelog generation (eg include esr/geckoview updates, etc)
Part of this has been done.
Room for improvement:
automatically sync the changelogs and write to the file without copying and pasting (it's possible to do some magic with GitPython, e.g., check if the last update was in maint-X or in main, or take the newest tag)
for each component, parse the YAML config at the previous release (which can be fetched with git show tag:projects/<project>/config), and check if var/version changed (or the addon URL, in case of NoScript and co.)
make it a function, so that we can run it from a relprep.py script ️
It doesn't handle QA+release emails and the site + blog MRs, but maybe they're a bit out of scope for it?
Especially the blog, for which we usually customize the post a little bit.
So, I'd close this even though they aren't automated (yet).