-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Standard release process #286
Comments
It would be great to make this a Markdown checklist in openforcefield/devtools/ Also, the PI approval can likely be replaced by a sufficiently mature checklist. Perhaps we can skip that step with the idea that, once we've established the process, PI sign-offs is no longer needed? PI input should come at the level of helping shape release plans earlier through communicating which issues are critical or urgent. |
That sounds good. I'm keeping this as an Issue for now, since it'll be easier to edit while we work out the process. But yes, we should transfer this into And I'm planning on removing point |
Some potential additions: The RTD docs didn't auto-update when 0.3.0 was cut. We should add some steps to the build checklist to ensure this happens:
|
Also, should we have a policy of back-porting the more detailed release notes on GitHub back into the sphinx docs release history? |
Per discussion on Slack, we should include the full-text names of functions whose behavior is changing, as well as functions being added or removed. This will be especially useful as we make a larger number of releases and users need to Ctrl-F to find a specific keyword. |
I don't want to introduce more back-porting than is absolutely necessary, so maybe we could draft the summary text in |
I have a couple of suggestions, in increasing complexity:
Some more thoughts are available here Keep A Change Log. |
@jaimergp Now that I've done this a few times, I definitely agree with the second point. The first seems circular, but maybe I'm not understanding it correctly (The RTD can't have a link to the release page, since the RTD is a snapshot of what the docs were at the time of release, so by defnition the release hasn't happened yet when the RTD content is set) |
@j-wags maybe append to this: Create a new placeholder section in the release history file for the next release. This way the first PR after a release isn't responsible for creating the new section and keeps things a bit more single purpose and less likely to create merge conflicts on the file! |
Great call. Added as step 4.75! |
@j-wags Yesterday we discussed adding a step to tap Binder so that the latest release would always be cached and ready to go. I checked around and this won't work; Binder doesn't have a facility to point to the latest release, only to a branch. So as soon as a pull request is merged after a release, the cache would be invalidated again. My suggestion to get around this would be to create a new branch, If you agree with that approach, should we automate updating the branch? It should be very easy to write a GH action that automatically updates the branch when a release is published, or at any other stage during the drafting of a release. An alternative might be to just link to the latest release tag directly, but that means at every release you'd have to update all the Binder links in the codebase. |
I think you can also use a moving tag instead of a branch. Or use the GitHub API to return the latest release tag. |
Quick clarification -- I think we had talked about this with respect to Binder, not Docker. Binder is using Docker behind the scenes, but currently that's out of our hands -- All we tell Binder is "do something with So, I assume you're talking about switching Binder to use a Docker image instead of that yaml file, which is a good idea. IIRC, public images are generally hosted on DockerHub. I can't recall whether we have an openforcefield dockerhub -- I had worked with @dotsdl on a start to this, but I can't recall the conclusion. We could make this image creation be a GitHub action that's automatically triggered by a release. This would also have us start publishing a dockerfile, which would close #416. |
Oops. I meant Binder. I was literally just talking about adding a new branch and changing the links to *Binder. So, from https://mybinder.org/v2/gh/openforcefield/openforcefield/master?filepath=%2Fexamples%2F To https://mybinder.org/v2/gh/openforcefield/openforcefield/latest?filepath=%2Fexamples%2F Now that you mention it though, we could just adapt these instructions to do what you're saying on release. I'll open a PR after the weekend. |
Seems like a much cleaner (and easier to write) solution than my git/shell-foo openff-toolkit/.github/workflows/conda.yml Lines 99 to 127 in e01e47c
|
1: Get approval from Jeff Wagner (or current product owner) to release main "as is"
2: Create a new release on GitHub, following this template:
https://github.com/openforcefield/openff-toolkit/releases/new
Tag =
X.Y.Z
@ masterTitle =
X.Y.Z [Descriptive Title]
Add the "See our install instructions" block verbatim from above
Check
This is a pre-release
, and clickRelease
!2.5: Update the stable tag to point to the newest release/latest commit
Just run this action
3: Trigger a new build on conda-forge.
Get a fork of the feedstock repo
If you don't have a personal fork of https://github.com/conda-forge/openff-toolkit-feedstock, then make one.
If you do have an old personal fork of https://github.com/conda-forge/openff-toolkit-feedstock, then update it with the most recent changes by running (replacing
j-wags
with your GH username)Update the build info
in
recipe/meta.yaml
, update0
if that's not already setcurl -sL https://github.com/openforcefield/openff-toolkit/archive/X.Y.Z.tar.gz | openssl sha256
Open a PR from your fork to conda-forge/openff-toolkit-feedstock
Follow instructions, including rerendeing and such. Once tests pass, go ahead and merge.
Test the package
4: Update repo text
Edit the release page to add the Zenodo badge by copying the version-specific badge from here.
Update the openforcefield README "Latest Release" badge. Also ensure the "How to cite" section is up to date. Just commit directly to
master
Make a new, empty
Current Development
header inreleasehistory.rst
Add something like the following to the top of
releasehistory.rst
Per @SimonBoothroyd:
5: Build the single-file installers
6: Update the ReadTheDocs build versions
stable
tag (since RTD doesn't care that we updated it on GitHub, we need to tell it explicitly to rebuild)7: Announce the release
Post something like this in #general
8: Tweet the release
9. Draft highlights for email
Communication & Outreach / News
on ConfluenceThe text was updated successfully, but these errors were encountered: