Release Procedure

This page summarizes the steps that need to be taken when performing the next major GRNsight release. Steps are manual for now, but documenting them is the first step toward facilitating automation in the future.

The list is coded up using checkboxes, so that its source can be copied into a GitHub issue as a starting point for preparing a new release.

• In the days leading up to the release, all open issues that need to be resolved before the release will be given the label "for next release".
• Any new or changed client-side features need to be documented on the Client Side Testing Document page.
  • the feature JSON files file should be updated
  • the new feature also needs to be added to the Pull Request Checklist
• Test the candidate build (typically the beta branch)
• Merge the branch(es) under development (typically beta) into master
  • Resolve any version control conflicts
  • Test the final merged version
  • Perform hotfixes on master as needed
• Update README.md at top-level directory of master branch, if necessary
  • Update Travis and Coveralls badges to reference the master branch
• Tag the final, tested version as v#.#.# (all three numbers are required, even if 0; see npm step below)
  • Update version numbers in package.json
  • Remember that the tag needs to be pushed to GitHub: git push origin <tag-name>
• Create draft release item on Github repository (name it exactly like the tag)
  • Make release notes: a list of new features/bug fixes with issue numbers covered by this release. Note that this at least will be the ones labeled "for next release", with possible others.
• Publish GitHub release item
• Publish release to GRNsight home page
  • Refresh (pull) the master clone on grnsight.cs.lmu.edu
  • Update the version number and modification date on gh-pages
  • Update the About page with release notes (GitHub release item without issue numbers)
    • Update the browser version compatibility statement with the latest version of Chrome and Firefox for which the new GRNsight version has been tested.
    • Update modification date
  • Add news item about the release to the News page
    • Update modification date
    • Link news item to the corresponding release notes in the About page
  • Update Documentation page with any new features or updates to old features
• Increment beta version
  • Merge released master with beta, especially if hotfixes/merges were made on master
  • Update version number and modified date on gh-pages
  • Update Travis and Coveralls badges to reference the beta branch
  • Refresh (pull) the beta clone on grnsight.cs.lmu.edu
• Publish to npm (npm publish)
  • npm requires all .0s in the semantic version
• Update version number/other relevant information at current bioinformatics listing sites
  • Elixir
    • Then change hyperlink on the GRNsight Links page, if necessary
• Get DOI for new release from Zenodo
  • Verify that the badge in README.md at top level of repo is correct (it might be necessary to invoke curl -X PURGE https://camo.githubusercontent.com/camo-GitHub-id in order to update the badge image)
  • Verify that CITATION.md file DOI links to the new release, updating if necessary
  • Verify that "How to cite GRNsight" section on About page links to the new release, updating if necessary