Things for Hatari dev team to check before new release... Contents: * When first thinking about new release * One or two weeks before release * Release candidate * Final release * After release When first thinking about new release ------------------------------------- * Get list of things we want to push in before the release - Make sure that any other larger changes are postponed after release * Ask about compatibility / bug fixes & features that people would like to see in next release * Check whether any of the (new) changes distro packages apply to Hatari sources should be in Hatari itself: - https://sources.debian.org/patches/hatari/ - https://src.fedoraproject.org/rpms/hatari/tree/main - https://packages.gentoo.org/packages/games-emulation/hatari - https://svnweb.mageia.org/packages/cauldron/hatari/current/ - https://build.opensuse.org/search?search_text=hatari One or two weeks before release ------------------------------- After changes deemed necessary have been implemented, check that everything that should work, does still work: * Ask people on hatari-devel to build latest Hatari and do some preliminary testing with their favorite use-cases * Run TOS boot tester for all supported TOS versions * Verify that: - Building different Hatari build configurations works: - all optional dependencies being present, and none - all optional features enabled, and disabled - Mac GUI - All above Hatari builds pass "make test" - Run Hatari with valgrind - Check a build with "cmake -D ENABLE_ASAN:BOOL=1". Use this if ASAN prints weird stack traces for leaks: export ASAN_OPTIONS="fast_unwind_on_malloc=0" - Check that everything built fine on Travis and Cirrus-CI: https://travis-ci.com/github/hatari/hatari https://cirrus-ci.com/github/hatari/hatari * Check that manual pages do not have errors: troff -man -w w $(git ls-files '*.1') > /dev/null * Check that all programs/demos listed in compatibility.html as fixed during early development still work, and make sure they're listed also in release-notes.txt * Check that (Python/Gtk) hatariui still works with latest changes, including starting with no existing Hatari config, saving changed config, and running under X11 & Wayland Release candidate ----------------- After found issues have been fixed, prepare for release candidate: * Check that Hatari documentation and WWW-site repository are up to date * Fix remaining x.x-dev versions in compatibility.html to new release: sed -i 's/x.x-dev/x.x/' * Validate HTML documentation with https://validator.w3.org/ * Go through commit log / ask others to make sure relevant changes are listed in release-notes.txt, and updated in todo.txt * Get latest etos1024.img version for binary packages and document that in emutos.txt * Build binary packages for OSes that aren't covered by the daily builds * Announce release candidate on mailing lists & Atari forum and ask people to test it on all platforms. Remember to tell which platforms should work, and which are still completely untested Final release ------------- If no release-critical issues were reported, do actual release: * Update release version & date in: + Sources: - src/includes/version.h - src/memorySnapShot.c (if needed) - Mac GUI plist files : src/gui-osx/Info-Hatari.plist src/gui-osx/Info-Hatari Winuae.plist src/gui-osx/en.lproj/InfoPlist.strings src/gui-osx/fr.lproj/InfoPlist.strings + Documentation: - readme.txt - doc/compatibility.html - doc/doxygen/Doxyfile - doc/debugger.html - doc/emutos.txt (based on latest EmuTOS release) - doc/manual.html - doc/release-notes.txt + Packaging: - hatari.spec * Build final binary packages * Announce new release "everywhere" * Party! After release ------------- * Switch back to devel, and increase devel version number in "src/includes/version.h" header