Skip to content

Release checklist

Jump to bottom
James Groom edited this page Apr 1, 2024 · 21 revisions

Note that some of these can be done concurrently.

  1. Choose to merge or not merge pending changes
    • Ideally there would be a release candidate and rigorous testing, but there never seems to be enough time...
  2. Test Issues labelled "Patch pending"
  3. Write the changelog
    • You can use git log --pretty='format:[%h %an] %s%n%b%n' 2.x.. (substitute the last release tag for "2.x") as a starting point. TODO write a bespoke tool for editing changelog
    • After parsing through the commits to get a list of user-facing changes (remember only fixes for bugs present in the last release need to be mentioned), group them as in the example below. Use past tense and all lowercase, omitting the period (if you find yourself needing to start a new sentence then you're being too verbose). It really doesn't matter if you use BrE or AmE spellings, just make sure that menu items are as shown in-app, which means AmE because that's the only localisation we provide at the moment. You should include Issue numbers for bugs and feature requests, but only link PRs when no Issue exists.
    • This needs to be prepended to /Assets/changelog.md (Markdown) immediately before updating the release branch so that it ends up in the build artifacts.
    • It also needs to be prepended to the ReleaseHistory article (TASVideos Wiki markup). Apart from changing markup language, also remember to include download links and the release date (will need to finish this after publishing).
    • There's also the ext. tool changelog. If an ApiHawk change doesn't affect Lua then it might not warrant inclusion on the main changelog, but this one includes even the tiny method signature changes.
  4. Update VersionInfo.MainVersion if it was set for a point release but this will be a minor release
  5. Update the release branch to point to master
  6. Check for AV false positives
    • Separately upload the release archive and EmuHawk.exe alone to VirusTotal. A false positive from the Microsoft engine is the only one that really matters.
    • If it does happen... add a random <EmbeddedResource/> to the assembly or something and try again idk ¯\_(ツ)_/¯
  7. Create a "Release" on GitHub
    • Check the date—if it's April 1st or thereabouts, ABORT MISSION. Seriously, it's just not worth it.
    • Set it to create a new tag.
    • GitLab CI will build the release branch shortly after pushing it. Grab the package_release_* artifacts, replace "VERSIONHERE" in the filenames, recompress the Linux release as .tar.gz, and attach them to the Release.
    • For the description, list any new or graduating cores, optionally some large improvements, and if the Windows prereq installer was updated link that too.
    • Click "Publish" and pray.
  8. Update Issues, Labels, and Milestone on GitHub
    • (where this release will be 2.x.1)
    • Rename "Fixed/added in 2.x.1 dev" to "Fixed/added in 2.x.1" (i.e. remove "dev"; do not rename "Affects 2.x.1 dev", these should be re-triaged).
    • Add "Affects 2.x.1", "Regression from 2.x.1", "Affects 2.x.2 dev", and "Fixed/added in 2.x.2 dev".
    • Add/update core labels
    • Create a new Milestone "2.x.2" with target date 3 months from this release.
    • Move some or all open Issues to the new Milestone. There's no policy for this as we don't really use it for project management.
    • Close the "2.x.1" Milestone.
    • If any Issue was critical enough to warrant pinning, but was fixed for this release, unpin it.
    • Re-triage Issues which were only reproduced on dev builds ("Repro: Affects 2.x.1 dev"), and Issues which affected cores that were updated in this release.
  9. Update VersionInfo.MainVersion and VersionInfo.ReleaseDate
    • ReleaseDate is overwritten by CI for release builds, but needs to be checked-in. MainVersion should be set to e.g. "2.x.2" after releasing 2.x.1.
  10. Update readme and other documentation pages
    • The version isn't explicitly written in any links or text in the readme, but the information itself might become outdated, especially the core list.
    • LuaFunctions on TASVideos Wiki
  11. Nix stuff?
  12. Hype
    • TASVideos news, Discord, etc.

Changelog structure

(see "Write the changelog" above)

Treat Libretro as just another core in this context. The cores under "Other cores:" are in alphabetical order, new/graduating aren't. The changes should be sorted with the most important first, but that's kinda subjective so don't try too hard. Obviously, omit empty headings.

- Misc. changes to EmuHawk:
	- change
- Linux port:
	- change
- TAStudio:
	- change
- Lua/ApiHawk:
	- change
- DiscoHawk:
	- change
- New and graduating cores:
	- new core:
		- change
	- graduating core:
		- change
- Other cores:
	- a core:
		- change
	- another core:
		- change
Clone this wiki locally