Prepare for OpenMS 3.2.0 release

[mr-c]

PR Type

documentation

---

Description

• Updated the documentation configuration to reflect the new version 3.2.0.
• Added a new entry for version 3.2.0 in the version switcher JSON file.

---

Changes walkthrough 📝

Relevant files

Documentation

conf.py Update documentation version to 3.2.0                                        docs/source/conf.py Updated the version variable from 3.1.0 to 3.2.0. Ensured the release variable reflects the new version. +1/-1      switcher.json Add version 3.2.0 to documentation switcher                            docs/source/_static/switcher.json Added new entry for version 3.2.0 with corresponding URL. Reordered entries to include the new version. +10/-0

---

💡 PR-Agent usage:
Comment /help on the PR to get a list of all available PR-Agent tools and their descriptions

[codiumai-pr-agent-pro]

PR-Agent was enabled for this repository. To continue using it, please link your git user with your CodiumAI identity here.

PR Reviewer Guide 🔍

⏱️ Estimated effort to review: 1 🔵⚪⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Key issues to review None

[codiumai-pr-agent-pro]

PR-Agent was enabled for this repository. To continue using it, please link your git user with your CodiumAI identity here.

PR Code Suggestions ✨

Category	Suggestion	Score
Best practice	Remove the unnecessary Unicode string prefix for consistency It is recommended to use a consistent string format for version numbers. The 'u' prefix is unnecessary in Python 3 for Unicode strings. Removing it will clean up the code and maintain consistency. docs/source/conf.py [85] -version = u'3.2.0' +version = '3.2.0' Apply this suggestion Suggestion importance[1-10]: 8 Why: The 'u' prefix is unnecessary in Python 3 for Unicode strings. Removing it improves code readability and consistency without affecting functionality.	8
Maintainability	Sort version entries in descending order for better maintainability Ensure that the new version entries in the JSON file are sorted in descending order for better readability and maintenance. This helps in quickly identifying the most recent versions at the top of the file. docs/source/_static/switcher.json [7-15] { "name": "3.2.0", "version": "3.2.0", "url": "https://pyopenms.readthedocs.io/en/release3.2.0/" -}, -{ - "name": "3.1.0", - "version": "3.1.0", - "url": "https://pyopenms.readthedocs.io/en/release3.1.0/" } Apply this suggestion Suggestion importance[1-10]: 7 Why: Sorting version entries in descending order improves readability and maintainability, making it easier to identify the most recent versions quickly.	7

[jpfeuffer]

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.

[mr-c]

Should I revert, tag, and then revert the revert?

[jpfeuffer]

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

[timosachsenberg]

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

[jpfeuffer]

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.

[jpfeuffer]

I guess this could be incremented as well to 3.3.0dev. Maybe wait until the actual version was incremented in OpenMS