OpenMM 7.5 release plan

[jaimergp]

Hi!

Peter, could you nominate a commit to start planning the release of v7.5? I want to base all the testing for the Conda Forge migration using something as close as possible to the final release. At least I need the Python 3.9 fixes (#2888) and the PowerPC / ARM fixes (#2499 #2781, maybe others?).

Thanks!

[peastman]

Use the current head of the master branch. That's 2c36e9b. The final release will be something very close to that.

[peastman]

Now that the build system is working (thanks to amazing work by @jaimergp!), I think we're just about ready to build the release candidate. Are there any final changes we should make first?

[peastman]

One change we need is to update the installation instructions in the manual. What will be the commands for installing it, including handling of different CUDA versions?

We also need to create builds of PDBFixer and OpenMM-Setup and update the installation instructions for them. Those should be easy since they're just Python.

[jaimergp]

What will be the commands for installing it, including handling of different CUDA versions?

I'll add PRs for that.

pdbfixer and openmm-setup can go to conda-forge once openmm is in main too. I can have the packages submitted beforehand to have minimal delays.

[peastman]

Great, thanks!

[jaimergp]

I can have the packages submitted beforehand to have minimal delays.

All the remaining omnia packages are being submitted in this PR: conda-forge/staged-recipes#13234

This won't be merged until OpenMM goes main, which will happen once 7.5 is released. In the meantime, we can test the packages through the linux artifacts because most are just noarch.

[peastman]

Perfect. That means we should finalize the code revisions for all packages. @jchodera your thoughts on openmm/openmm-setup#20 would be much appreciated.

[peastman]

I think we're now ready to build the release candidate?

I'll make final changes to PDBFixer and OpenMM-Setup so we can build packages for them at the same time as the official OpenMM release, probably sometime next week.

[jchodera]

@peastman: Since these packages depend on OpenMM, we can't build them at the same time. Instead, we should get OpenMM out to the conda-forge channel and then worry about the dependencies. But nothing can happen until then, I don't think.

[peastman]

Oops - in testing the PDBFixer updates, I just discovered another OpenMM bug that needs to be fixed. PR coming in a moment.

[peastman]

Ok, I merged the fix. Now we can continue!

[jaimergp]

PDBFixer and OpenMM-Setup are included in conda-forge/staged-recipes#13234.

Since these only depend on OpenMM, I can probably split them to a separate PR so it's easier for conda-forge core to review them.

[jaimergp]

Ok, I merged the fix. Now we can continue!

Can we nominate a new hash to work as RC?

[peastman]

83e9213. That's the current head of the master branch.

[peastman]

Should we also include #2935? It fixes an error in a new feature that was added in 7.5. The risk is hopefully fairly low, since if you don't enable periodic exceptions, it shouldn't affect anything. But of course, nothing is without risk.

[jchodera]

Seems like it makes sense to not ship a release with known bugs if we can avoid it.

[peastman]

Ok, merged. The head of the master branch is now b49b82e.

[jaimergp]

Looks like the last builds at conda-forge are fully operational. Shall we nominate those as the rc?

Instructions to install would be:

conda create -n openmm-750-rc -c conda-forge/label/test -c conda-forge openmm 
conda activate openmm-750-rc
python -m simtk.testInstallation

Or with a specific cudatoolkit:

conda create -n openmm-750-rc -c conda-forge/label/test -c conda-forge openmm cudatoolkit=10.0
conda activate openmm-750-rc
python -m simtk.testInstallation

[jchodera]

@peastman : I suggest we do the following for this release process:

• Cut a "prerelease" 7.5.0rc1 release on GitHub that will contain all the information about how to download, test, and report issues. Crucially, unlike the SimTK page, @jaimergp and I will both be able to update the release notes.
• We share that release link on twitter and other channels and ask people to test
• If all goes well, @peastman can cut an official 7.5.0 release on Mon and @jaimergp can update the conda package on Tue morning Europe time

[peastman]

Awesome! The final thing we need to do is a minimal test following the procedure at https://github.com/openmm/openmm/wiki/Release-Candidates. That means installing on Linux, Windows, and Mac, and for each one verify that 1) all expected platforms work, 2) the version number is correct, and 3) the git revision is correct. Once that's done I can post to the forum.

If all goes well, @peastman can cut an official 7.5.0 release on Mon and @jaimergp can update the conda package on Tue morning Europe time

We usually wait a full week after a release candidate. If we get really a lot of people testing it by Monday we could accelerate it, but that might be pushing it a bit.

[peastman]

The Linux build lists

Git Revision: c54f33c7c63d0ff58dd90aab52e5ec10e18f74f8

That isn't the correct revision. It's supposed to be b49b82e.

The Mac build lists

Git Revision: Unknown

[jaimergp]

Yes, I am observing the same behavior in my tests.

I am obtaining the source tarballs using the /archive endpoint in GitHub. Is that supposed to work with the git_revision parsing? The revision in these tarballs might not obtainable as expected...

[jaimergp]

I am going to try and patch the version.py file in the conda recipe. If that doesn't work, we can also try to clone the repository, but that doesn't work as nicely for reproducible builds...

[peastman]

I am obtaining the source tarballs using the /archive endpoint in GitHub. Is that supposed to work with the git_revision parsing?

No idea. In the past we've specified the revision directly:

https://github.com/omnia-md/conda-recipes-cuda/blob/3798691b217ff9b49a53a1c453846d8b20df92d4/openmm/meta.yaml#L5-L7

[jchodera]

@jaimergp : Would it help if we cut a 7.5.0rc1 release and used that for the conda-forge build?

Once that's done I can post to the forum.

The goal is to collect all the documentation for installing and using it---and any FAQs and answers---in the release notes that we post on GitHub. You can announce this in the forum and link to it, but it is important we do not make the forum the primary source of release information that everything points to.

[peastman]

We have a standard procedure for this: https://github.com/openmm/openmm/wiki/Release-Candidates. Release notes, documentation, FAQs, etc. go with the release, not the rc.

Nothing else needs to point to the forum post, but I'm still going to include the installation instructions in the post. If we want people to test the release candidate we should make it as easy as possible. Besides, I'm going to discuss how things have changed since the beta, which will include examples of different ways of installing.

[peastman]

Looks like the builds are done, so I'm starting on testing.

[peastman]

Everything looks good! I can't test CUDA on Windows since I don't have a Windows box with an NVIDIA GPU, but that will have to do.

[jaimergp]

I'll do the Windows testing tomorrow!

[peastman]

Let's go ahead then! The OpenMM-Setup and PDBFixer releases should each be built from the head of the main branch. That's cb256e2 for OpenMM-Setup and f02ecdb for PDBFixer. I can create the Github releases.

We also need to put the up to date version of the documentation in the latest folder for docs.openmm.org. I think you may need to do that.

[peastman]

Except that first I need to update the version number for OpenMM-Setup. Just a moment.

[peastman]

Ok, the OpenMM-Setup revision is 015e21d.

[peastman]

Github releases have been created for all three repositories.

[jchodera]

Let's go ahead then! The OpenMM-Setup and PDBFixer releases should each be built from the head of the main branch. That's cb256e2 for OpenMM-Setup and f02ecdb for PDBFixer. I can create the Github releases.

Can you remind me why we are building from commit hashes instead of releases? This is an unusual practice, and I do not understand why we are doing this.

[jaimergp]

PR to publish in main available here: conda-forge/openmm-feedstock#41

I'll open the PRs for setup and pdbfixer at staged-recipes once that one is merged!

[jaimergp]

Can you remind me why we are building from commit hashes instead of releases?

The releases are indeed based off tags now. The unusual cycle was during the RC builds. OpenMM, OpenMM-setup and PDBFixer are being built using tags now, but in the case of OpenMM we need the full repo to include the revision hash in the version.py file.

[jaimergp]

As long as we have a rollback plan (to move it back to test if things go wrong)

I'll be around but in case this is needed urgently, that workaround is described here.

[jaimergp]

PR to publish in main available here: conda-forge/openmm-feedstock#41

Ready to pull the trigger :)

[peastman]

Go for it!

[jaimergp]

Merged!

[jchodera]

@peastman: Can we note that we now deploy through conda-forge in the release notes, or at least link to the new installation instructions in the manual that specify installation via conda-forge?
https://github.com/openmm/openmm/releases/tag/7.5.0

[peastman]

As soon as we get the new documentation posted! Are you planning to do that or should I?

[jchodera]

As soon as we get the new documentation posted! Are you planning to do that or should I?

No idea what you're referring to, so could you go for it?

We have (had?) a release checklist, but I'm not even sure where that lives or where we are on that process anymore.

[jchodera]

Let me know if you need any help from S3 side, though!

[peastman]

docs.openmm.org has a folder for each release containing its documentation, and another folder called latest that gets updated to always have the documentation for the latest release. I'll update them.

[jchodera]

docs.openmm.org has a folder for each release containing its documentation, and another folder called latest that gets updated to always have the documentation for the latest release. I'll update them.

Let me know if you need any changes from the S3 console.

[peastman]

Docs are uploaded and I added a link to the installation instructions.

[peastman]

How about the OpenMM-Setup and PDBFixer builds? Are they ready to go?

[jaimergp]

Waiting for the CDN to sync up (+60 mins after seeing the package on anaconda.org). Once that happens (in 15 mins), I'll push to staged-recipes and then, after review, they will have their own feedstock and packages.

[jaimergp]

Before I submit the recipes, pdbfixer needs a version bump here: https://github.com/openmm/pdbfixer/blob/master/setup.py#L37

[peastman]

Done! Sorry I missed that before.

[jaimergp]

I'll need the tag moved to that commit too, sorry! 😬

[peastman]

Done. Some people are just so hard to please! 😀

[jchodera]

I've just tweeted the release announcement:
https://twitter.com/openmm_toolkit/status/1337118945640255488

I'll tweet more about the new 7.5.0 release over the next few days, but it would be great if we could update the benchmarks online. In particular, it would be useful to provide useful benchmarks---most people will not have access to Titan Vs, but 2080s.

[jaimergp]

PR for openmm-setup and pdbfixer available here: conda-forge/staged-recipes#13443

Please add a comment to confirm you want to be a maintainer on the feedstocks. Thanks!

[jaimergp]

Both are live!

• OpenMM Setup: https://anaconda.org/conda-forge/openmm-setup/files
• PDBFixer: https://anaconda.org/conda-forge/pdbfixer/files

[peastman]

I think this means we can close the issue! Thanks for the amazing work @jaimergp.

[jaimergp]

This is such a nice way to start my holidays! Thanks!