Release checklist » History » Version 19

Version 18 (Paul Bauer, 11/29/2018 01:55 PM) → Version 19/21 (Paul Bauer, 12/31/2018 04:02 PM)

h1. Release checklist

* add new redmine version targets
* bump bugs that won't get fixed in time to next version (or untag a version number)
* check the post-submit and nightly Jenkins matrices are building suitably well
* merge in appropriate branches from earlier releases
* if regressiontests changes with matching source changes are needed, do the cross-verify checks to see that things are working, and plan to submit the patches either early or the very last thing, to minimize mysterious Jenkins failures because an outdated parent is in use
* announce release schedule - give devs a week or two to fix things they intended to fix, provide links to gerrit and redmine pages for that branch/version
* bump shared object minor version for point releases
* consider bumping shared object major version for point releases - see cmake/gmxVersionInfo.cmake for policy
* check for new GROMACS papers that should be mentioned in source and manual

* run release workflow a few days in advance to check things work
- this also builds the tarball correctly, when the RELEASE checkbox is ticked, which we need for updating the REGRESSIONTEST_MD5SUM in cmake/gmxVersionInfo.cmake
- TODO automate this along the lines of the regressiontests auto-builder

* put stuff on the FTP site only when ready to make the release announcement, as some distros automatically scan URLs for tarballs
* upload source tarball to FTP site, give correct permissions, check link works - TODO automate the stuff below into a Jenkins job that we trigger manually after the release workflow is satisfactory

Here's a script to help automate that on Jenkins

# Jenkins is able to work out what the version is for the
# Release_workflow_master, so we can put that to use for the publish
# workflow, too.



download="wget -N"

upload="rsync -avP --chmod=u+rwX,g+rwX,o+rX"
$download "*zip*/"
cp ${website_tarball}
# Unpack the website tarball
cd /tmp
unzip -o -u $originalpwd/${website_tarball} #>& /dev/null
echo "done unzip"
ls Website/*
$upload Website/* Website/.[a-z]* $deploymentlocation/${version}/
echo "done upload"
cp Website/manual*pdf $originalpwd
#rm -rf Website

# Get the various tarballs and manual to the ftp server. Note that the
# GROMACS source repo has in the URL for the
# regressiontest tarball download, but actually the requests are
# redirected to server.
upload="rsync -avP --chmod=u+rw,g+rw,o+r"
$upload $source_tarball $destination/gromacs/
$upload manual-${version}.pdf $destination/manual/
$upload $regressiontests_tarball $destination/regressiontests/

# Echo these to the terminal for convenient double checking
md5sum $source_tarball
md5sum $regressiontests_tarball

* update symlinks for current version in www at /var/www/documentation
* update News on front of GROMACS web page -
* TODO make notes of what goes into the commit for the new version and the one that follows the tagged commit
- check the contents of the release notes, particuarly for commits since the last release that have no
release notes yet, e.g. with @git log --oneline@ vs @git log --oneline -- docs/release-notes@
- tag the commit from which the tarball was made, and do explicit upload to repo
- update REGRESSIONTEST_BRANCH if needed (major release)
- sometimes bump GMX_VERSION_* variables
- bumps to release notes index.rst and directory structure

* once the gerrit change is submitted and the release email sent, make tag of the correct form in local repo
* bump version in cmake/gmxVersionInfo.cmake in the commit following the tag (look at previous release commits) - prepare this commit in advance, finalize any TODO on the day
* add new stub file for release notes for next version, and entry in index.rst in commit to follow teh release commit
* git push --tags to gerrit repo
* later, check tags propagate to gromacs and github

* get main website documentation from bitbucket repository:
* edit index.rst to include new version/updated point release
* check that script does what it should do and if necessary update the script (example below)
set -x


# Re-make the top-level documentation for all versions
make html

# Ensure useful read permissions when placing on a server
upload="rsync -avP --chmod=u+rwX,g+rwX,o+rX"
$upload -av _build/html/ $deploymentlocation/ --exclude _sources --exclude .buildinfo --exclude objects.inv
* run script in top level of bitbucket butbucket repository
* check that website has been updated correctly

* post on gmx-users and gmx-announce.
* post on Google+ and Facebook pages
* thank gmx-developers
* bump/close/update open redmine issues
* close completed redmine versions
* beer

TODO some recent examples of post-release emails

To make this work, mark and pbauer are members of www group on (which is still running some old OS that can support the old WWW server software), and ftpadmins on, and the respective directories have write permissions for that group. TODO update the above logic to make sure that rsync sets the group attributes to those groups.