openforcefield/openff-forcefields

Standard release process

j-wags opened this issue · 1 comments

j-wags commented

Based on openforcefield/openff-toolkit#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: 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

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

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

8: 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)