# Tablicious Release Checklist

Here's the process for doing a Tablicious release.

1. Make a new `release/v<version>` branch for the prep work and switch to it.
1. Run all the tests.
    1. `tblish_inst = fullfile(getenv('HOME'), 'repos', 'octave-repos', 'tablicious', 'inst')`
    1. `addpath(tblish_inst)`
    1. `__run_test_suite__ ({tblish_inst}, {})`
    1. `tblish.internal.runtests`
    1. Run the MP-Test tests
        1. `addpath(fullfile(getenv('HOME'), 'repos', 'octave-repos', 'mptest', 'lib'))`
        1. `tblish_mptest_tablicious`
    1. Wouldn't hurt to do `make clean && git status && make test` and manual-cleanup, just to be sure.
1. Update the version info in the repo.
    1. Update the version number and date in `DESCRIPTION`.
        1. Remove the `-SNAPSHOT` suffix from the version number.
    1. Update the `CHANGES.txt` file with the release date.
        1. Use the current calendar date in UTC time, not your local time.
        1. And check that it has a complete change list for the release. This _ought_ to be done as changes are committed, but we're not good about that at all, so assume it didn't happen.
1. Update the installation instructions in `README.md` to use the upcoming release tarball URL.
    1. Format is: `https://github.com/apjanke/octave-tablicious/releases/download/v<version>/tablicious-<version>.tar.gz`
    1. As of 2024-10, this is just in the "Quick start" section.
1. Commit the changes so far with commit message `[release] v<version> - prep`.
    1. Use form: `git add -A; git commit -a -m '[release] v<version> - prep'`
1. Update the generated doco.
    1. Regenerate the doco: `make doc; make gh-pages`
    1. Make a versioned copy for this release:
        * `ver=$(grep ^Version DESCRIPTION | cut -d ' ' -f 2); mkdir -p docs/release/v${ver}/user-guide; cd doc; cp -R html tablicious.html tablicious.pdf ../docs/release/v${ver}/user-guide`
        1. What is wrong with you, Andrew? Make this a `make` target instead of a 200-character-long bash cut-and-paste command.
    1. Update `docs/index.md` with the new release.
        1. Add a section for the new release's doco under Releases.
        1. Update the links in the first paragraph in User Documentation to point to the new release, and the release number in the second paragraph.
1. Commit the regenerated doco with commit message `[release] v<version> - doco`.
    1. Use form: `git add -A; git commit -a -m '[release] v<version> - doco'`
1. Make sure your repo is clean: `git status` should show no local changes.
1. Run `make dist` first to make sure it works.
    1. This has to be done _after_ the commit, because it extracts from git history.
1. Test the dist tarball.
    1. Install it with `pkg install <path/to>/target/tablicious-x.y.z.tar.gz`.
    1. Run tests on the installed package.
        1. `pkg test tablicious` will do the BISTs. (But only the oruntest-discoverable ones?) Prob have to run the MP-Test suite manually for now.
    1. Preferably on both Mac and Linux, and maybe Windows.
1. Merge the `release/v<version>` branch to `main` and switch to `main`.
1. Create a git tag and push it and the above changes to GitHub.
    1. `git tag v<version>; git push; git push --tags`
1. Create a new GitHub release from the tag.
    1. Just use `<version>` as the name for the release, not `v<version>` or `v <version>`.
    1. Copy and paste the changes for this release from the `CHANGES.txt` file into the GitHub Release description field.
    1. Upload the dist tarball as a file for the release.
1. Test installing the release using `pkg install` against the new release URL.
    1. Do this by copy-and-pasting the `pkg install` example from the [live README page](https://github.com/apjanke/octave-tablicious/blob/master/README.md) on the GitHub repo. This makes sure the current install instructions are correct.
        1. Don't short-circuit this by just editing an entry from your Octave command history! Open GitHub in a browser and actually copy-and-paste it.
    1. Run tests on the installed package, like above.
1. Open development for next version.
    1. Update version number and date in `DESCRIPTION` to next patch or minor version, as appropriate.
        1. Include a `-SNAPSHOT` suffix to indicate this is a work in progress.
    1. Add a section to `CHANGES.txt` for the new upcoming release, at the top. Use `(unreleased)` for its release date.
    1. `git add -A; git commit -a -m '[release] open development for next version (<x.y.z>)'; git push`
1. Close the GitHub Issues [Milestone](https://github.com/apjanke/octave-tablicious/milestones) for this release.
    1. Create a new Milestone for the next release, if one doesn't already exist.
1. Announce the release.
    1. Update the OF packages index info in the gnu-octave/packages repo.
        1. Put in a PR to the [`gnu-octave/packages` repo](https://github.com/gnu-octave/packages) to update `packages/tablicious.yaml`.
            1. Add a new item to its `versions` section for this new release.
            1. See example: [Tablicious index update for 0.3.7 - 0.4.2](https://github.com/gnu-octave/packages/pull/401).
    1. Add a comment to the [Tablicious News issue](https://github.com/apjanke/octave-tablicious/issues/131) with a link to the new release.
    1. Post an announcement on the [Savannah bug for datetime support](https://savannah.gnu.org/bugs/index.php?47032) if this is a significant release with respect to the date/time classes.

If there were any problems following these instructions exactly as written, please report it as a bug.
