Release Checklist

Steps for making a release

1. (optional) Create a release branch and create a pull request for it against main.
   • This is not strictly necessary, but I have found that during the pre-release testing process multiple small bugs are uncovered. Having an unprotected branch available to push changes to allows you to iterate more rapidly. Otherwise all individual changes will need to go through the PR review and testing process.
2. Edit the file ldm/invoke/_version.py to bring the InvokeAI version up to the desired release number.
3. Edit the file installer/create_installer.sh to update the PATCH variable. During the pre-release process this variable will contain the release candidate number in the form "rcX", for example "rc1". When the script generates the installer files, it concatenates the version number from _version.py to the patch number, yielding a tag of the form vX.X.X-rcX.
4. Run create_installer.sh from within its directory. It does three things:
   • It tags the tip of the current branch with the pre-release tag, vX.X.X-rcX
   • It moves the tag latest to the tip of the current branch. latest is used by update.sh to upgrade the user's install to the latest version of InvokeAI. So during the pre-release process, users who run update.sh will get the pre-release (unless they explicitly specify a different tag to fetch). This was designed to make it easy for users to test the pre-release, but on reflect I think it might be better to have two tags, one named latest-release attached to the most recent release, and the other latest-prerelease for the pre-release.
   • It creates four zip files. Three for the Windows, Linux and Mac installers, and one for the update script. The installers also install the exact same update script, so if users have installed 2.2.5 or later, they already have the script in their invokeai directory.
5. Go to the InvokeAI Releases Page and push the Draft New Release button.
6. You will be prompted to select or create a tag for the release. Select the one chosen in step (2).
7. Write the release notes. There is a GitHub button labeled Generate release notes that will automatically insert the changelog and new contributors. I use this to generate the bottom half of the release notes, and the tried and true method of cutting and pasting from the previous release notes to write the intro.
8. Upload the four zip files created in step 4 into the Assets section of the release notes. I also like to upload them into the body of the release notes, since it can be hard for users to find the Assets section.
9. Check the Set as a pre-release and _Create discussion item` checkboxes at the bottom of the release page, and Save.