-
Notifications
You must be signed in to change notification settings - Fork 53
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
Prepare for OpenMS 3.2.0 release #440
Conversation
PR-Agent was enabled for this repository. To continue using it, please link your git user with your CodiumAI identity here. PR Reviewer Guide 🔍
|
PR-Agent was enabled for this repository. To continue using it, please link your git user with your CodiumAI identity here. PR Code Suggestions ✨
|
{ | ||
"name": "3.1.0", | ||
"version": "3.1.0", | ||
"url": "https://pyopenms.readthedocs.io/en/release3.1.0/" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This does not exist. We need to add a tag to a commit that is before the merge commit of this PR, to trigger a build of a 3.1.0 version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should I revert, tag, and then revert the revert?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess just tagging should be fine to get some docs for 3.1.0.
A general problem is however is that these docs here build both Tutorial AND API docs.
And API docs are currently hardcoded to parse whatever is the latest on our pypi:
https://github.com/OpenMS/pyopenms-docs/blob/master/docs/requirements.txt#L9
So, if you now tag an older commit of pyopenms-docs as 3.1.0, and rebuild on RTD, you will get tutorials and ipynbs for 3.1.0 but API docs for latest. Unfortunately, even reverting would not solve this.
Only reverting, fixing the underlying issue, tagging, revert the revert might fix it.
A fix would involve running a pip install DURING the doc build, not before, based on the version that is present in the conf.py
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm would this mean we would need to somehow check if available and fetch the python artifacts from our python whl job (instead of using pip with our pypi) and install them from the downloaded whl? also pinging @poshul for input
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think ideally, a successful run of pyopenms-wheels on develop (or a release tag/branch) would trigger a docs build with the same artifact (which should be uploaded to our pypi anyway, right?).
And a standalone docs build would use the latest build for the version specified in the conf.py.
Also the pyopenms version that is imported in the tutorial notebooks should be dynamic. Otherwise, if you open Binder for an old release tag, it would install the latest version instead. Currently everything is just working for nightlies (except that the non-API docs are kind of versioned.
@@ -4,6 +4,16 @@ | |||
"version": "3.1.0dev", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this could be incremented as well to 3.3.0dev. Maybe wait until the actual version was incremented in OpenMS
PR Type
documentation
Description
Changes walkthrough 📝
conf.py
Update documentation version to 3.2.0
docs/source/conf.py
version
variable from3.1.0
to3.2.0
.release
variable reflects the new version.switcher.json
Add version 3.2.0 to documentation switcher
docs/source/_static/switcher.json
3.2.0
with corresponding URL.