duktape/doc/release-checklist.rst

=================
Release checklist
=================

* Git branch naming note

  - ``vNN.NN-release-prep``: use this naming for bumping version number, etc.
    Merge to master before tagging release.

  - ``vNN.NN-release-post``: use this naming for bumping version number after
    release, checklist fixes after release, etc.

* Git maintenance

  - ensure git commits are up-to-date

  - ensure branches are merged, unused branches deleted (also remotely)

  - ensure branches are rebased where applicable

  - git fsck --full

  - git gc --aggressive

* Ditz maintenance

  - Ensure Ditz issues for the new release are all closed

* Finalize DUK_VERSION

  - Change previous development version (with patch level 99) to release
    version

  - Verify by running Duktape cmdline and evaluating ``Duktape.version``

* Check dist-files/README.rst

* Ensure LICENSE.txt is up-to-date

  - Check year range

* Ensure RELEASES.rst is up-to-date (must be done before candidate tar.xz
  build because dist package contains RELEASES.rst)

  - New release is in place

  - Release log entries match ditz issues

  - Release date is in place

* Compilation tests: clean compile with common debug options
  (DUK_OPT_DEBUG, DUK_OPT_DPRINT, DUK_OPT_SELF_TESTS, DUK_OPT_ASSERTIONS)
  and with no debug options:

  - **FIXME: incomplete list, automate compilation tests**

  - Linux x86-64 gcc

  - Linux x86-64 gcc + -m32

  - Linux x86-64 clang

  - Linux x86-64 clang + -m32

  - FreeBSD clang

  - FreeBSD clang + -m32

  - Windows MinGW

  - Windows MinGW-w64

  - Windows MSVC (cl) x86

  - Windows MSVC (cl) x64

  - Windows Cygwin 32-bit

  - Windows Cygwin 64-bit

  - Linux MIPS gcc

* Ecmascript testcases

  - **FIXME: semiautomate test running for various configurations**

  - On x86-64 (exercise 16-byte duk_tval):

    - make qecmatest   # quick test

    - VALGRIND_WRAP=1 make qecmatest  # valgrind test

  - On x86-32 (exercise 8-byte duk_tval)

    - make qecmatest   # quick test

  - Run testcases on all endianness targets

  - Run with assertions enabled at least on x86-64

* Memory usage testing

  - Leaks are mostly detected by Valgrind, but bugs in valstack or object
    resize algorithms (or similar) can lead to unbounded or suboptimal
    memory usage

  - XXX: establish some baseline test

* API testcases

  - On x86-64:

    - make apitest

* Regfuzz

  - On x86-64, with DUK_OPT_ASSERTIONS

    - make regfuzztest

* test262

  - on x86-64

    - make test262test

  - Run with assertions enabled at least on x86-64

* emscripten (run emscripten-generated code with Duktape)

  - on x86-64

    - make emscriptentest

* emscripten (compile Duktape with emscripten, run with Node)

  - on x86-64

    - make emscriptenduktest

* JS-Interpreter

  - on x86-64

    - make jsinterpretertest

* lua.js

  - on x86-64

    - make luajstest

* Git release and tag

  - Tagging should be done before creating the candidate tar files so that
    "git describe" output will have a nice tag name.

  - This will be a preliminary tag which can be moved if necessary.  Don't
    push it to the public repo until the tag is certain not to move anymore.

  - There can be commits to the repo after tagging but nothing that will
    affect "make dist" output.

  - ``git tag -l -n1`` to list current tags

  - ``git tag -s -m "<one line release description>" vN.N.N`` to set tag

  - ``git tag -f -s -m "<one line release description>" vN.N.N`` to forcibly
    reset tag if it needs to be moved

* Build candidate tar.xz files

  - These should remain the same after this point so that their hash
    values are known.

  - Check git describe output from dist ``README.rst``, ``src/duktape.h``,
    and ``src/duktape.c``.  It should show the release tag.

* Check source dist contents

  - Check file list

  - Grep for FIXME and XXX

  - Trivial compile test for combined source

  - Trivial compile test for separate sources (important because
    it's easy to forget to add files in make_dist.sh)

* Store binaries and update website downloads page

  - Release date

  - Link

  - Date

  - "latest" class

  - Release notes (layout and contents) for release

* Build website

  - Readthrough

  - Test that the Duktape REPL (Dukweb) works

  - Check duk command line version number in Guide "Getting started"

* Ditz release

  - ``ditz release vN.N``

  - git add and commit ditz issues

* Upload website and test

* Final Git stuff

  - Ensure ``master`` is pushed and unnecessary branches are cleaned up

  - Push the release tag

* Bump Duktape version for next release and testing

  - Set patch level to 99, e.g. after 0.10.0 stable release, set DUK_VERSION
    from 1000 to 1099.  This ensures that any forks off the trunk will have a
    version number easy to distinguish as an unofficial release.

  - ``src/duk_api_public.h.in``

* Update ``DITZ_RELEASE`` in ``Makefile``

  - It should point to the next expected release so that ``make issuecount``
    and ``make issues`` provide useful output