Because I always seem to forget one step or another when creating a new version of my add-on, I decided this time to make myself a nice checklist. Let’s hope that when I find out I forgot something this time too, I remember to update the checklist π
β Fix bug or implement a new feature.
β Update status of tickets on SourceForge.
β Git push the changes to SourceForge and GitHub.
β Document the changes in the release notes and in the version history.
β Upload alpha/beta version to BabelZilla and Crowdin so localizers can translate it.
β Create screenshots showing where new strings are used to help localizers and upload them to Crowdin.
β Verify that the new version works as expected Windows, Linux and Mac.
β Verify that the new version works in the latest Thunderbird and is also compatible with older versions.
β Verify that the new version works in the latest SeaMonkey and is also compatible with older versions.
β Verify that I have downloaded and merged all language changes and synchronize them also on BabelZilla and Crowdin.
β Verify that all strings in all languages are localized and if not, urge localizers to do so.
β Decide on the version number of the new version x.y.z. Only bug fixes? Increase z. New function? Increase y.
β Finalize the release notes and version history and update the compatibility info.
β Build the new version for SourceForge and for addons.thunderbird.net.
β Generate sha256 checksum and gpg signature for the new version for SourceForge.
β Git push the new version and gpg signature to SourceForge.
β Upload the new version to SourceForge and move old version to archive.
β Wait a bit until the new version has been copied to SourceForge’s mirrors and shows up as the latest version.
β Update the website with the release notes, version history, new download link, and auto update information.
β Verify that auto update from older versions of Mail Redirect to new version works.
β Register the new version on SourceForge’s ticket system, close the old version and create a new target version.
β Git push the website to SourceForge to save version history.
β Draft the release also on GitHub and make it available.
β Write a message to the mailing list to tell people about the new release, functions, and bug fixes.
β Do the same in a blog post.
β Wait a bit for reactions.
β Submit the new version of Mail Redirect to the review queue of addons.thunderbird.net.
β Keep fingers crossed that it isn’t automatically rejected by the automatic validation process because of an error I made.
β Wait a couple of days before the add-on is reviewed and accepted by one of the volunteer reviewers.
β Wait a couple of more days and ping a volunteer reviewer on irc and ask him/her to review my add-on.
β Keep an eye on the download and usage statistics to see the uptake of the new version and wonder about how many people are still using an older version even though Mail Redirect is backwards compatible.
β Ask for donations to support the continued development show how happy you are to use this add-on.
oeekker's blog 
September 15, 2019 at 6:45 am |
[…] No point to it, it's #proprietarysoftware and it's controlled by your competition and the #nsa https://oeekker.wordpress.com/2019/09/14/checklist/ […]
September 15, 2019 at 7:44 am |
And here’s the first thing I forgot to do:
β Manually change the compatibility range for Thunderbird and add SeaMonkey on addons.thunderbird.net, since this information isn’t picked up from install.rdf anymore.