Standardize the release process

[Ricardo Vieira]

We should release again with the patch from #61

It looks like the last conda version was released without updating the python version, so it shows as 0.8.1 while it is called 0.9.0. ??

Then we did a recent 0.9.0 release on github/pypi that corresponds to something more like 0.9.1 (it includes #61 which was merged yesterday)?

On PyPi we see this: https://pypi.org/project/nutpie/#history
On Github we see this: https://github.com/pymc-devs/nutpie/releases

Basically we have two things called 0.9.0, that are different in the two sources (excluding #61 in conda, and including it in PyPi)
Probably we should bump the python version to 0.9.1 and release again to synchronize (and more importantly get #61 on conda)

[Thomas Wiecki]

Let's just do a clean 0.9.1.

[Adrian Seyboldt]

I'm not 100% sure what's wrong, but I guess we need a short release checklist...

Something like

• Check if any cargo dependencies had semver changes, eg using cargo outdated (needs a plugin), and update those if possible.
• Update cargo dependencies in the lock file: cargo update
• Bump version in Cargo.toml
• Update changelog with git cliff (unfortunately this only captures changes that are done using conventional commit messages)
• Make a commit with those changes
• Make release PR on github, wait for tests to complete and merge
• Make a github release
• Check that the release pipeline runs properly
• Wait for a bot PR on the nutpie-feedstock or do one manually and get that merged.

Something missing?

[Chris Fonnesbeck]

BTW the CHANGELOG file is out of date.

[Thomas Wiecki]

Yeah we should move to auto-release notes.