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 inextras:
- If we have
upload: beta
, we would install withconda install -c omnia/label/beta openforcefields
- PR should be called, eg
- 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)
dotsdl commented
MIgrated to a wiki page for this repo: https://github.com/openforcefield/openforcefields/wiki/Release-Process