- minor release: create the 0.4.X branch, branching from upstream/main & push upstream
- create a branch like `release-0.4.0` or `release-0.4.1`, branching from main
- edit the changelog and `VERSION.txt`
- replace "ongoing development" with 0.4.1
- in version.txt replace eg 0.4.dev0 with 0.4.0 or 0.5.dev0 0.4.1
- build the wheel & test it
- `rm -r dist skrub.egg-info`
- `python -m build` (may need `pip install build`)
- `twine check dist/*` (may need `pip install twine`)
- in a directory outside of the skrub repo
- install the wheel in a fresh virtualenv
- pytest --pyargs skrub
- git commit
- if we are doing a bugfix release (0.4.X already existed before) we need to rebase on the existing 0.4.X
- run `git rebase -i upstream/0.4.X`
- all commits that have been made on main that we want to keep will be replayed on top of the last release's tag in 0.4.X
- open a PR on `0.4.X`
- this will update the doc for the stable release
- while it runs we can prepare a PR on the *main* branch to be merged after the release:
- if it was a minor (not patch) release:
- the VERSION.txt should be updated to 0.5.dev0
- the changes.rst: create a header for the new entries
- we need to update doc/version.json which contains the version numbers of the stable release and dev branch. once this json file is updated on the main branch in the repo, the warn
- merge the PR on 0.4.X (don't squash the commits)
- no squash see warning in https://scikit-learn.org/dev/developers/maintainer.html#reference-steps
- note: in normal times only squash&merge is enabled because that's what we want for the main branch and we don't want to rebase or merge without squashing my mistake. there seems to be no way to configure this per branch ATM on github. so when we do a release we temporarily enable rebase. go to repository settings -> general -> pull requests, enable rebase, then merge the PR on 0.4.X (with the rebase option), then in the settings disable it again
- look at the rendered doc for the built 0.4.X branch, the examples, the changelog
- now we build the wheel we will upload to pypi locally git fetch upstream and git checkout upstream/0.4.X
- build the wheel & test it
- `rm -r dist skrub.egg-info`
- `python -m build`
- `twine check dist/*`
- install the wheel in a fresh virtualenv
- pip install pytest numpydoc
- pytest --pyargs skrub
- upload to pypi
- in theory: upload to test pypi, install & check, and only then upload to pypi
- in practice: skip
- `twine upload dist/*`
- tag the release commit
- `git tag -s '0.4.0'`
- `-s` is for signing, optional
- `git push upstream tag 0.4.1`
- if you have configured your .git/config so that the pushurl for upstream is some wrong url (a good safety measure), temporarily comment out that line so that you can push the tag
- merge the PR on main that updates the version number & version.json
- update symlink to stable version in the github branches repo: https://github.com/skrub-data/skrub-data.github.io
- only needed for minor release, not patch relesase. eg change symlink from 0.3 to 0.4
- update the conda-forge recipe
- in `skrub-feedstock` https://github.com/conda-forge/skrub-feedstock
- create branch `release-0.4.0`
- update `recipe/meta.yml`
- that is the only file we ever edit manually in that repo
- update version number
- update sha256
- if needed reset build number to 0
- if needed update the requirements (easiest way to check is in skrub checkout 0.4.2 git diff 0.4.1 -- pyproject.toml)
- open pr to `upstream/skrub-feedstock` main branch
- use checklist that will be posted in pr
- in particular it asks to post a comment asking a bot to re-render the
recipe, make sure to wait until that has finished
- then merge the pr. it can take around an hour (maybe more?) for the
package to be available from the conda-forge channel
- when it becomes available, install in a fresh env & test
- NOTE: to add new maintainers to that repo add them to the list at the end of meta.yml

- if it works, announce the release on social network channels

TODO: read [this comment](https://github.com/conda-forge/skrub-feedstock/pull/7#issuecomment-2504196814) and update skrub-feedstock/recipe/meta.yml accordingly. we can push and re-build the package in this skrub version (just remember to bump the "build number") or leave it for the next skrub release.