Another similar project: `cargo smart-release`

[Byron]

I am leaving this here in case you weren't aware. It allows me to release inter-dependent crates in the right order with changelogs automatically. The version is also determined automatically based on conventional commits.

https://github.com/Byron/gitoxide/tree/main/cargo-smart-release

I will close this issue immediately as it's just a way to send a message.

[Byron]

No action required.

[marcoieni]

Hi Byron! Thanks for reaching out. I had a look at cargo-smart-release before writing release-plz, it's a great project!
I have some questions for you:

• how does cargo-smart-release determine which commits to consider for the current release? I.e. which commits are "new"? Do you look at local git tags to check which was the last published version? For example, release-plz downloads the last published crate version from crates.io and compares the content of the files to identify which commit was released on crates.io.
• Do you want cargo-smart-release to generate GitHub PRs like release-please does or do you see the future of cargo-smart-release as CLI only?

My ultimate goal is to create a flow that works entirely in CI.

[Byron]

You are welcome, thanks for your reply and questions. Here we go.

how does cargo-smart-release determine which commits to consider for the current release? I.e. which commits are "new"?

It knows where the crate lives and then finds all commits that change anything within its root path (without rename tracking though). It stops if it reached a commit that is tagged by the previous tag that it created itself. This means the change tracking only works if the releases are marked with tags, and it's crucial to help with segmenting the history to be able to build changelogs.

It appears that release-plz can do that without needing any tags, which is pretty awesome. It's something I didn't consider even, so it's good to add to the list of options should it ever be necessary.

Do you want cargo-smart-release to generate GitHub PRs like release-please does or do you see the future of cargo-smart-release as CLI only?

There is no desire to bind it to GitHub or its CI and it's only meant to be used locally. Having CI do most of the work is definitely a unique selling point of release-plz and it's great to have that option.

I can highly recommend to put cargo-release and its maintainer @epage on your radar, he has heaps of experience related to releasing crates, among other things, and talking to him to bounce ideas might be helpful to reaching your ultimate goal faster (or less painfully). Maybe one day cargo-release will learn some new tricks that you prototype here if there are generally valuable and he super quick in adopting these as well.

[epage]

For me, I don't think I can fully trust in commits to determine what is safe to release. This mostly stems from if you have a repo with multiple "things" in it, like a workspace of crates. Observing myself, I've seen times where a commit is marked as fix, feat or with ! that touched multiple crates but multiple crates the scope only applied to one of the crates. I see using commit parsing as a way to advise users on issues at most.

Oh, I guess this just bumps the version only. Since that gives the developer an opportunity to review it (as long as the automation doesn't blind them to reviewing it), that works. I'm used to the fully automated release tools like cargo-release were if version selection is integrated, then there won't be a chance to review it.

@marcoieni a couple of questions

• Any reason you selected conventional_commit_parser instead of git-conventional?
• How do you determine what the base commit is?
  • Ok, did some more digging, it looks like you find the latest version on crates.io and then walk backwards until you find a version of the crate that matches that version. Is that correct? Any thoughts on the issues of crates moving (I just moved several of mine) or a patch for a prior major release?

Also, @Byron as an aside, I think you'd find this RFC conversation starting with cart's post interesting as it could be useful for gitoxide as well

(save myself the trouble of finding a way to message you ;) ).

how does cargo-smart-release determine which commits to consider for the current release? I.e. which commits are "new"?

atm cargo-release only looks at commits for reporting which packages have changed to help catch users who skip releasing packages. I've just not gotten around to adding any more smarts.

So when we do this, we take the current crate version and construct a tag name from that and then compare that to HEAD.

Do you want cargo-smart-release to generate GitHub PRs like release-please does or do you see the future of cargo-smart-release as CLI only?

Like with @Byron, I've been avoiding coupling to a service but instead rely on the release process triggering any related workflows, like binary releases or populating the github release.

My ultimate goal is to create a flow that works entirely in CI.

I raised a question about that when first using cargo-release and still find the topic interesting to explore though as I've streamlined my workflow with cargo-release and dealt more with the workspace problems, I've not focused as much on this as what I'm doing is "good enough" for now. Granted, one area I still need to explore is smoothing out the changelog process. cargo-smart-release handles things one way but I think there is still more room for experiments in different directions.

[marcoieni]

It appears that release-plz can do that without needing any tags, which is pretty awesome.

Yes, exactly! release-plz should be able to work with any project. I don't want to enforce tag naming conventions and things like this.

Oh, I guess this just bumps the version only. Since that gives the developer an opportunity to review it (as long as the automation doesn't blind them to reviewing it), that works.

Yes, exactly! The idea is to open a PR or do the changes locally without doing any commits. In this way, developers can review the changes, do some manual edits and commit when they are happy.

Any reason you selected conventional_commit_parser instead of git-conventional?

I used conventional_commit_parser because for the version bump part I took inspiration from the cocogitto codebase.

Ok, did some more digging, it looks like you find the latest version on crates.io and then walk backwards until you find a version of the crate that matches that version. Is that correct?

Exactly!

Any thoughts on the issues of crates moving (I just moved several of mine)

No, I opened #27. If you have some ideas on how to do it, can you please leave a comment there?

or a patch for a prior major release?

What do you mean? 🤔

Anyway, thanks both for the positive feedback :)

[epage]

Yes, exactly! release-plz should be able to work with any project. I don't want to enforce tag naming conventions and things like this.

`cargo-release doesn't force the use of tags or a tag naming convention. It defaults to tagging and has a default tag name template. Both are configurable by users. With tags, we get the benefit of checking history but we can release without it.

or a patch for a prior major release?

What do you mean? thinking

So you compare against the highest version of crates.io. That assumes I'm releasing a version right after it. What if I want to patch a prior release. Let's use clap as an example. We are on clap 3.1.x. What if there is a motivating case to to a hot fix for 3.0.x or 2.x? release-plz will download the latest crate and walk the history to the origin of time, not finding a release that matches up. because 3.1.6 doesn't come before 3.0.10.

While this doesn't happen often in the cargo ecosystem, ti will more so as we mature.

Yes, exactly! The idea is to open a PR or do the changes locally without doing any commits. In this way, developers can review the changes, do some manual edits and commit when they are happy.

The downside is this doesn't take into account any changes that happen between running release-plz update and and merge and then CI doing release processes.

While I don't run into this in my own projects, I have had people ask to harden cargo-release so that it works even when new changes are made while racing for the release. See crate-ci/cargo-release#147

For now, the most we do is warn the user when the remote is ahead of the commit they are releasing. We still need to create the merge-commit, if needed, to fully close the race.

[marcoieni]

What if I want to patch a prior release.

I see, you are right. You can't do it right now, but maybe release-plz could accept a "registry version" parameter where you specify the version you want to patch. Also, you need to specify the correct git branch if you want to raise a PR (I imagine you are using a git flow workflow and you don't want to target main in this case).

While this doesn't happen often in the cargo ecosystem, it will more so as we mature.

Yes, for now I will focus on the usual workflow of trunk-based development.

The downside is this doesn't take into account any changes that happen between running release-plz update and and merge and then CI doing release processes.

Probably this is a problem for the project that does the actual release (e.g. cargo-release) instead of release-plz, which is only responsible for updating the versions (and changelog soon). I don't want to rewrite that part :)
Or am I wrong here? 🤔

[epage]

The downside is this doesn't take into account any changes that happen between running release-plz update and and merge and then CI doing release processes.

Probably this is a problem for the project that does the actual release (e.g. cargo-release) instead of release-plz, which is only responsible for updating the versions (and changelog soon). I don't want to rewrite that part :) Or am I wrong here? thinking

You still have a race. The window is between running release-plz and merging the PR. Any commits that happen between those times won't be included in the version calculation (and the changelog in the future) but will be in the release.

The likelihood of hitting this race depends on the project size and coordination among those with merge-access. For me, I more so found I had forgotten to do a git pull to get existing commits before starting the process (cargo-release will do a git fetch and warn if you are behind upstream) but apparently others run into the issue of new commits.