Release Process

Based on https://github.com/openforcefield/openforcefield/issues/286

This is something like a pre-flight checklist to make sure we don't make unnecessary errors in the process of releasing new FFs.

1: Prepare changes in a PR

• Open a new branch or fork on this repo.
• Add the new force field file to the branch.
• Draft a "version" description at the bottom of the README file in a branch or fork. A zenodo DOI link is not necessary at this stage
• Prepare a link to the fitting tarball, which is often associated with a release like this. This collection of assets should include:
  • a static copy of the data (QM and phys prop) used for the fit
  • a static copy of the scripts used for the fit
  • A file containing the environment used for the fit (like the output of conda env export)
  • Generally, anything else required to re-run the exact fit that was performed
• Open a PR to master, for example this

2: Get PR approved by at least one repo maintainer

• Check that regular and unconstrained forcefields have constraints applied and absent, respectively
• Ensure that new FFs are loadable in newest stable release of OFF toolkit
• Ensure that there are no cosmetic attributes
• Visually inspect for whitespace irrgularities etc
• Ensure that comments, dates, and authors are up to date

3: Cut an official release, following this template:

Tag = X.Y.Z @ master

Title = Version 1.0.0 "Parsley"

The new force field files in this release are adapted from `result.offxml` in `release_1.0.0_RC2.tar.gz` from the Assets of [`OpenFF "parsley" 1.0.0-RC2: Fitting Valence with QM Data`](https://github.com/openforcefield/release-1-fitting/releases/tag/v1.0.0-RC2)

A blog post summarizing the benchmarking of this FF will be published in the near future at https://openforcefield.org/news/ 

4: Edit the README page to add the most recent Zenodo badge by copying the version-specific badge from here. Information needs to be added in two places:

• The badge needs to be added to a new row in the "filename -> DOI" table in the README
• The "Versions" text at the bottom of the README should be update with the doi.org link for the version release.

5: Copy the latest version of the version/DOI table to https://github.com/openmm/openmmforcefields/issues/115, overwriting the original post

6: Trigger build of the new release on Omnia

• Create branch or fork of omnia-md/conda-recipes with changes to openforcefields in meta.yaml:
  • version set to match git release
  • tag set to match git release
  • build set to 0
  • any updated dependencies reflected under requirements:
  • If we want to push to special beta label: use extra.upload
• Open PR to merge branch or fork into omnia-md master
  • PR should be called, eg [smirnoff99Frosst] 1.0.10
  • No PR body text is needed
  • PR is then reviewed and merged by omnia maintainers
  • Package is pushed to beta label if upload: beta is set in extras:
  • If we have upload: beta, we would install with conda install -c omnia/label/beta openforcefields
• Test omnia package

7: If this is a major release, update FFs in Open Force Field toolkit examples

8: If this is a major release, rebuild most recent OFFTK single-file installer with new version of openforcefields

9: Announce the release!

• Announce in the Open Force Field Slack's #general (Do a @channel blast if it's a major release)
• Announce on twitter if it's a major release
• Announce on Open Force Field mailchimp list (@davidlmobley can provide access)