Things for Hatari dev team to check before new 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/master
  - 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
    - WinUAE & oldUAE CPU cores
    - SDL1 & SDL2
    - Mac GUI
  - All above Hatari builds pass "make test"
    - 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 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 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 etos512.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:
  - version.h
  - manual.html
  - debugger.html
  - compatibility.html
  - readme.txt
  - release-notes.txt

* Build final binary packages

* Announce new release "everywhere"

* Party!
