[RELEASE] Minterpy v0.4.0

[damar-wicaksono]

This issue tracks the release process for Minterpy v0.4.0. The checklist is organized into three phases:

• preparing the release on dev,
• merging to and tagging main, and
• verifying the release.

Steps are sequential. Specifically, several pre-merge steps must be completed before pushing the tag, as the tag push immediately triggers the release workflow and publishes to PyPI with no opportunity to intervene.

Pre-merge (on dev branch)

Complete all steps in this section before touching the main branch.

• Merge or defer all in-scope issues to dev (see the Milestone)
• Update CHANGELOG.md (this will serve as the basis for the GitHub release notes in the post-release step)
  • Rename [Unreleased] to [v0.4.0] - YYYY-MM-DD and update its comparison link to diff against the previous tagged release (the link will appear broken until the tag is pushed in the next phase: this is expected)
  • Create a new empty [Unreleased] section at the top with a comparison link between HEAD on main and dev
• Build and verify documentation (no broken references, no build warnings)

CI pipelines include a documentation preview served to GitHub pages but to save time the notebook-based documentation is not executed; make sure you can build the documentation of the dev branch locally.

• Create a new draft version for the release in RODARE without publishing to reserve DOI (do this before merging to main so the DOI can be embedded into the README file as part of the tagged commit) (@szabo137)
• Update README.md with the new DOI (badge and citation section)
• All CI checks passing on dev (tests, build, docs-preview, coverage)

Merge, tag, and push

• Merge dev into main (via Pull Request)

⚠️ This is the point of no return: the next step creates and pushes the tag, which triggers the release workflow automatically. The workflow pushes the artifacts to PyPI and creates a GitHub release with all attached artifacts. PyPI does not allow re-uploading a package with the same version. Verify all pre-merge steps are complete before proceeding.

The package version is derived automatically from the tag via setuptools_scm and written to src/minterpy/version.py at build time. Ensure the tag follows the format v0.4.0 exactly, as this becomes the version string on PyPI.

• Create an annotated tag: git tag -a v0.4.0 -m "Release v0.4.0"
• Push the tag: git push origin v0.4.0

Post-release verification

• Verify the GitHub Actions release workflow completed successfully
• Verify the GitHub release page was created correctly (tag and attached artifacts)
• Write and publish the release notes on the GitHub release page (the current draft is in Issue Decide if a new release is warranted #86)

The GitHub Actions workflow creates the release page automatically upon tag push but leaves the release notes empty. Populate them manually from CHANGELOG.md.

• Upload the release artifacts from the GitHub release to the RODARE draft and finalize and publish the release (@szabo137)
• Verify the DOI resolves correctly in RODARE
• Verify install from PyPI in a clean environment:
  • pip install minterpy==0.4.0
  • python -c "import minterpy as mp; assert mp.__version__ == '0.4.0'"

[damar-wicaksono]

@szabo137: I'm preparing the release now. At some point, I would need your help creating a draft upload in RODARE to reserve A DOI for the new release. I will let you know when. Thanks!

[szabo137]

At some point, we should automate away the Rodare upload (I mostly know how this works)

[damar-wicaksono]

Hi @szabo137: There's no open issues related to the upcoming release anymore. If you could give me the DOI for the archived version in RODARE, I would start the release procedure early next week. Thanks a lot!

[szabo137]

Hi @damar-wicaksono sorry for no reaction from my side, I was a bit busy with business trips and the like. I will take care of this next week 🙆‍♂️