Byron
commented
2 years ago Thanks for starting the conversation, it's great to get other perspectives and input. Let me CC @epage, the maintainer of cargo-release, as well in case it's of interest.
That said, I think it is a nice addition! Having some sort of 'checkpoint' commit would solve the problem of ever-growing histories which will slow down releases over time as one can prevent the search past a particular checkpoint. As changelog editing is non-destructive, it would simply leave the past history untouched, so that should work.
Renaming and relocation would indeed be solved like this as well, and it's something I didn't consider yet while considering to implement rename tracking due to my growing desired to move the git- crates from the top-level into a directory. Rename tracking is something that has to happen nonetheless, I think, but it's orthogonal to the mechanism proposed here.
A way to implement this would be to add another parameter to the headers of such commit to make them uniquely identifiable, and it should be possible to add another flag on the command-line to cause it to be written. The biggest problem to keep in mind is that sometimes, releases are made in multiple steps as they fail in the middle, requiring several attempts to complete in full. Then it would be on the user to only use the commandline flag the first time, and not during future attempts to complete the release.
Summary 💡
Create a mode of cargo-smart-release that is aware of special commits with type "release". The idea being that release commits are where changelogs and versions are automatically updated, and the commit description identifies which of the crates are being released. This has the benefit that a. it provides a way to signal to CI which things need to be released (by reading the commit description), b. the tool can know that it is only traversing back to the last release commit, c. and because it doesn't go past the release commit they act as a safe place to rename/relocate crates.
What do you think about adding this flow to cargo smart-release?
Motivation 🔦
I'm working on developing a release process for wit-bindgen, a Bytecode Alliance project, which has multiple crates that I would like to version more separately using something like cargo smart release. The features I'm asking for would help us implement the proposed process without requiring a ton of maintainer work.