Stop using make-historical #2312
Conversation
Eric-Arellano
changed the title
There was a problem hiding this comment.
Good idea!!
This script was introduced while still using the web crawler and qiskit.org IIRC. Runtime and Provider didn't publish more than one version, and it was necessary at that time. I remember we decided to keep it afterward to have a safe mechanism to convert a version into a historical one in case something happened to the CI artifacts (like if they expire). See #332
Since we have the artifacts stored in Box, I don't see any other advantage than just the speedup obtained when generating a new version, given that we avoid using the gen-api twice. On the other hand, the script has got more complex with all the handling of the release notes and links and I think it would be better to use gen-api as you propose. That way we avoid having to update in two places when changing something in the future.
I tested the differences between running make-historical and gen-api with the historical argument for Qiskit and Runtime, and the output was the same but fixing the metadata issue.
-title: visualization (latest version)
-description: API reference for qiskit_ibm_runtime.visualization in the latest version of qiskit-ibm-runtime
+title: visualization (v0.33)
+description: API reference for qiskit_ibm_runtime.visualization in qiskit-ibm-runtime v0.33
Closes #2269.
That issue made me realize I'm not sure why we have been using
make-historicalall this time rather thannpm run gen-apiwith--historical.gen-apiwill correctly handle setting up the new folder. For Qiskit SDK,gen-apiwill ensure the release note links are updated correctly for the historical notes, like1.2.mdxlinking to/api/qiskit/1.2rather than the unversioned files.