HOWTO-Release

How to make a ScummVM release.

This is work in progress and needs to be completed!

Preparations

Making the release plan
Telling people about it, making sure everybody knows what is going on

Testing & Branching

Identify release critical (show stopper) bugs and get people to fix them.
Identify other important bugs and get people to fix them.
Get even more people to fix all the other bugs, if possible :-).
Get people to do lots of testing, possibly by asking for help via a news item.
Collect all that information (e.g. in the Wiki). See Release Testing

Preparing the source

You have to update the versions in all relevant files. There is a script, tools/update-version.pl meant to help you with this. It will generate/update the following files:
- base/internal_version.h
- dists/macosx/Info.plist
- dists/redhat/scummvm.spec
- dists/scummvm.rc
Review the following documentation files for version and copyright year updates:
- README
- NEWS
- COPYRIGHT
Review the following port specific files for version updates:
- backends/platform/gp2x/build/README-GP2X
- backends/platform/gp2x/build/README-GP2X.html
- backends/platform/ps2/READ_PS2.TXT
- backends/platform/psp/README.PSP
- backends/platform/symbian/README
- backends/platform/wince/README-WinCE.txt
Make sure package descriptions are up-to-date:
- dists/redhat/scummvm.spec
Make source tarballs, post them in the SF.net FRS.
- There is a script tools/dist-scummvm.sh, which does this automatically.

Binaries

Get porters to make binaries.
- Porter must follow our filename convention, which goes like this: "scummvm-VERSION-PORT.EXTENSION". For example: "scummvm-1.1.0-macosx.dmg". Do not use special names like "EScummVM" or "ScummVMDS". The only exclusion from this requirement is Debian.
- Here is a list of files porters should include in their release archives:
  - AUTHORS
  - COPYING
  - COPYRIGHT
  - NEWS
  - README (generic ScummVM one)
  - scummclassic.zip (if your port uses new GUI)
  - scummmodern.zip (if your port uses new GUI)
  - pred.dic (from dists directory)
  - kyra.dat (from dists/engine-data)
  - queen.tbl (from dists/engine-data)
  - sky.cpt (from dists/engine-data)
  - lure.dat (from dists/engine-data)
  - drascula.dat (from dists/engine-data)
  - teenagent.dat (from dists/engine-data)
  - your build binary
  - your build-specific README (optional)
  - ...
Update the website internally (i.e. update the version in the repository), but do not yet put these changes online.

News & Notification

Write a news blurb (or rather multiple to be used in the following). Usually, you want a bit longer one for the website, a list for Versiontracker, something with proper english sentences for Freshmeat, etc....

Write a news item for our website (and as template for news items on other sites).
Update documentation page to link to the new README.
Update link to release notes (on downloads.php) to point to the correct new release notes in the SF.net FRS.
Update / notify various sites:
- Create a SF.net news item (Ender, Fingolfin, Sev, ...)
- Freshmeat (Ender, Fingolfin, ...)
- Versiontracker.com (Fingolfin)
- Update heise software directory (Fingolfin)
- ... more ?
Put the updated web site online
In the File Release System, use the "Notify" feature to make sure everybody who's interested in new releases gets a mail

Updating the wiki

Update Template:StableVersion. This is used for links to the Compatibility page for the stable version and for the latest stable version info field for each platform.
Move newly supported engines in the Complete engines in the latest stable version section on the Engines page.
Add the first release field on the info box of the newly supported engines.
Update Platforms page if status changed for some of the platforms (e.g. no release for the latest stable version). For these platforms the latest stable version info will also need to be changed if it was using the StableVersion template.
Update the support field on the info box of the newly supported games. Also remove these games from Unsupported Games category.