Release: MAME 0.288

[cuavas]

Create release branch

• Pull latest master branch, and run make cleansrc
• Check differences, manually clean up anything broken (useful to check git diff -b as well as git diff to see changes that affect things other than whitespace)
• Do a full build with DEBUG=1 TOOLS=1 to ensure changes compile/validate
• Check software lists against DTD: for x in hash/*.xml ; do xmllint --noout --valid "$x" ; done
• Check software hash files’ XML structure: for x in hash/*.hsi ; do xmllint --noout "$x" ; done
• Commit changes and push to master branch
• Create release branch and push to GitHub
• Push branch point to master branch on GitLab and SourceForge
• Create new version on MAME Testers with anticipated release date (last Wednesday of following month, 00:00:00Z), marked unreleased

Run build matrix

In addition to the basic coverage provided by GitHub Actions, MAME needs to be built and tested across a representative spectrum of configurations.

For the following configurations, ensure a build compiles, links and validates, -listxml output validates, and basic functionality works:

• x86-64, MinGW, clang, debug, SDL OSD, with Qt debugger, without tools
• x86-64, MinGW, clang, debug, SDL OSD, with Qt debugger, with tools, tiny subtarget
• x86-64, MinGW, clang, debug, SDL OSD, with Qt debugger, with tools, virtual subtarget
• x86-64, MinGW, clang, debug, Win32 OSD, without tools
• x86-64, MinGW, clang, debug, Win32 OSD, with tools, tiny subtarget
• x86-64, MinGW, clang, debug, Win32 OSD, with tools, virtual subtarget
• x86-64, MinGW, clang, non-debug, SDL OSD, with Qt debugger, without tools
• x86-64, MinGW, clang, non-debug, SDL OSD, with Qt debugger, with tools, tiny subtarget
• x86-64, MinGW, clang, non-debug, SDL OSD, with Qt debugger, with tools, virtual subtarget
• x86-64, MinGW, clang, non-debug, Win32 OSD, without tools
• x86-64, MinGW, clang, non-debug, Win32 OSD, with tools, tiny subtarget
• x86-64, MinGW, clang, non-debug, Win32 OSD, with tools, virtual subtarget

For the following configurations, ensure a build compiles, links and validates, -listxml output validates, minimaws ORM check passes, and basic functionality works:

• x86-64, Linux, GCC, libstdc++, debug, with tools
• x86-64, Linux, GCC, libstdc++, debug, without tools, tiny subtarget
• x86-64, Linux, GCC, libstdc++, debug, without tools, virtual subtarget
• x86-64, Linux, GCC, libstdc++, non-debug, with tools
• x86-64, Linux, GCC, libstdc++, non-debug, without tools, tiny subtarget
• x86-64, Linux, GCC, libstdc++, non-debug, without tools, virtual subtarget

For the following configurations, ensure a build compiles, links and validates:

• i686, Linux, GCC, libstdc++, debug, with tools
• i686, Linux, GCC, libstdc++, non-debug, with tools

Generate preliminary release notes

• Pull latest release branch from mame repository and latest master branch from build repository
• In build repository, run script to scrape commits and pull requests, e.g. python3 makewn.py -C ../mame -u <user> -o whatsnew/whatsnew_0124.txt
• Get -listxml output from previous release from a download mirror
• Generate -listxml output with a preliminary build from the release branch
• In build repository, run script to identify added/promoted/renamed/removed machines, e.g. python3 newdrivers.py mame0123.xml new.xml | tee -a whatsnew/whatsnew_0124.txt
• Copy resolved bugs from MAME Testers change log page to relevant section in release notes
• Before any editing, commit generated release notes for reference

Prepare release notes

• Reconcile added/promoted systems and software with credits in commit messages and pull request descriptions, moving entries to the relevant sections at the top, and sorting correctly
• Check commit log for language folder and list updated translation in the relevant section at the top
• Sort resolved bugs and edit descriptions
• Summarise merged pull requests, making verb tense consistent
• Standardise contributor names
• Strategically use non-breaking spaces to hopefully avoid line breaks at inopportune points
• Add anticipated release date to top line
• Commit changes, push to master branch, and let people know it’s ready for proof-reading

Build release

• Pull latest release branch
• In build repository, scrape latest commits, do a final check of release notes, commit changes, and push to master branch
• Ensure version is updated in android-project/app/src/main/AndroidManifest.xml (two lines), docs/source/conf.py (two lines), and makefile (two lines)
• Ensure there are no uncommitted changes on release branch
• Create signed, annotated tag for release, e.g. git tag -s -m"MAME 0.124" mame0124
• Clone mame repository into a clean directory and check out release tag, e.g. git clone -b mame0124 mame mame-release
• In new clone, double-check that git describe and git log -1 show what’s expected
• Use commands from build-release.bat in build repository to build 64-bit release binaries, e.g. (make TARGET=mame TOOLS=1 SEPARATE_BIN=1 PTR64=1 OPTIMIZE=3 SYMBOLS=1 SYMLEVEL=1 REGENIE=1 -j9 ARCHOPTS="-msahf -mcx16 -mpopcnt -msse4.2 -fomit-frame-pointer -fuse-ld=lld" OVERRIDE_AR=llvm-ar && make -f dist.mak PTR64=1 -j5) |& tee ../build64.log
• Check build log for anything suspicious
• Double-check that build repository is up-to-date
• Use release.sh from build repository to package release, e.g. bash ../build/release.sh 0124

Prepare media

• Add previous release to oldrel.php
• Copy release notes to releases folder
• Create release announcement post in posts
• Add content from release notes above the “Source changes” heading to release announcement below the <!--more--> tag, adding HTML markup for formatting
• Ensure MAME Testers bug numbers, GitHub pull request and issue numbers, and anything else relevant are linked correctly
• Use <tt> formatting for literal code, command-line options, etc.
• Write executive summary above the <!--more--> tag – aim for at least three paragraphs of content, call out a few interesting or notable changes
• Put release announcement post in a simple HTML wrapper, preview it, and check for HTML syntax/nesting errors
• Commit changes to web site pages
• Convert executive summary to UBB flavours for forum.mamedev.org and forums.bannister.org, and markdown flavours for reddit and GitHub, and check previews

Upload assets for release

• Push release tag to GitHub, GitLab and SourceForge
• Push tagged release revision to master branch on GitLab and SourceForge
• Pull latest master branch from GitHub, merge release tag, and push to master branch on GitHub
• Delete release branch on GitHub
• Create draft release on GitHub and upload assets
• From another browser instance, download assets from draft release
• Use 7za t to test integrity of downloaded archives
• Verify SHA1 and SHA256 digests, e.g. sha1sum -c < SHA1SUMS and sha256sum -c < SHA256SUMS
• Set timestamp on assets to midnight UTC for release date, e.g. TZ=utc touch -t 201909040000 0.213/* 0.213
• Upload assets, to SourceForge FRS, e.g. rsync -avzhc --progress -e ssh 0.124 frs.sf.net:/home/frs/project/mame/mame/

Publish release

• Mark current version as released on MAME Testers, and update with actual release date
• Publish release on GitHub
• Push web site changes to master branch and wait for static pages to be regenerated
• Check HTML and RSS pages, ensure a few links work
• Create forum threads on forum.mamedev.org, forums.bannister.org, and mameworld.info
• Create reddit posts on r/MAME, r/emulation and r/cade
• Create a new, pinned GitHub Discussion in the Announcements category, and unpin the previous release announcement discussion
• Update version number in topic on #mame on Libera IRC
• Announce release in announcements channel on Discord
• Update system driver source file list on MAME Testers (use scripts/xslt/list-system-sources.xslt to generate the list)