Release situation

[bbaldino]

Carrying on some discussion from here, I'd like to figure out how to get releases going again.

We have a bit of an issue in that two releases (0.1.4 and 0.1.5) do not have corresponding tags in the repo, but from here it looks like the best we can do may be to tag those hashes accordingly and then move on. I think we need to make sure we don't do any releases until that's done, or we could have conflicting version numbers that point to different hashes.

Separate from this would be something like getting some CI/github actions to automatically do releases...that'd be nice but I think let's get the "manual" releases back in shape before discussing that.

@chrysn @kjetilkjeka @Kijewski thoughts?

[chrysn]

I don't think that we'd get conflicts from later releases as long as the version in Cargo.toml has been increased accordingly -- at least cargo release (the only automated release tool I have any experience with) just takes the version in the Cargo.toml and creates a tag for that, disregarding earlier versions.

I have no experience with release processes that involve GitHub (or any other hosting platform, for that matter), I've only ever done releases locally (possibly from a PR branch, but even then I push the proposed change without the tag, wait for reviewers and CI to say Go, do a local cargo release based on that branch, which tags the PR'd change, and then merge the PR). If we trust GitHub with crates.io upload credentials and you find a suitable actions based release process, I'd be fine with that as well.

[bbaldino]

I don't think that we'd get conflicts from later releases as long as the version in Cargo.toml has been increased accordingly -- at least cargo release (the only automated release tool I have any experience with) just takes the version in the Cargo.toml and creates a tag for that, disregarding earlier versions.

Mainly I'm worried about the git tags: I think we should tag the hashes used for releases with a matching tag (it makes it easy for people to check out the code for a specific release which is useful). I was just thinking it'd be good to attempt to add some git tags for the prior releases as well, but you're right that as along as we do the next one correctly we shouldn't run into a problem.

I have no experience with release processes that involve GitHub (or any other hosting platform, for that matter), I've only ever done releases locally (possibly from a PR branch, but even then I push the proposed change without the tag, wait for reviewers and CI to say Go, do a local cargo release based on that branch, which tags the PR'd change, and then merge the PR). If we trust GitHub with crates.io upload credentials and you find a suitable actions based release process, I'd be fine with that as well.

I do think it'd be nice to get some automated releases going (this would require we do something like conventional commits as well) but don't think it's urgent right now.

[BenLeadbetter]

I use an automated git-flow release tool: https://github.com/CJ-Systems/gitflow-cjs

It's a bit of an oldskool release flow, but I find it very effective for managing things like tagging and syncing the main and develop branches.