cargo-deb VS cargo-release

I mean, there's tools that make it easy to make a .deb https://crates.io/crates/cargo-deb

The Rust Project itself had put a lot of work into making sure that Rust and Rust-using programs could get into Debian by working with Debian folks to address issues.

I suspect that you've run into an anecdotal pattern, but I'm not sure that it is more than that.

I use Cargo deb to create Debian / Ubuntu / ... package files.

As a suggestion if you want to get a lot of users you could make a .deb file that packages the binary and a systemd service file. Using cargo-deb it's pretty trivial, the hardest part would be writing your systemd service file and you can probably just copy the dunst.service file with minimal modification:

https://crates.io/crates/cargo-deb https://github.com/kornelski/cargo-deb

cargo install does provide different options to change the installation dir (https://doc.rust-lang.org/cargo/commands/cargo-install.html) but I am uncertain, if there could be accociated issues. An alternative could be tools like https://github.com/mmstick/cargo-deb or https://github.com/iqlusioninc/cargo-rpm that can automatically create packages which can be used for a proper installation /usr/bin/ using your distributions packaging system.

Cargo already has one: https://crates.io/crates/cargo-deb

My problem with maintaining a changelog during development is it can serve as a source of merge conflicts. Instead, I follow Covnentional Commit style and manually write my changelog entries based on the commits. I have a tool [0] that can show me the relevant commits for a package in my repo and automates the entire release process, including doing sanity checks.

I also feel like releasing from CI is hard, especially if you have multiple packages in a repo [1], including

- You can't as easily introspect the process

- You can't as easily recover from failure

- Getting a lot of the nuance right, like handling releases concurrent to merging of PRs, is difficult

- When the workflow is an ever-present "release PR" that you merge when ready has issues with selecting which packages to release and at what version

I have been considering making a tool to generate changelogs from fragments. Been keeping notes at https://github.com/epage/epage.github.io/issues/23

[0]: https://github.com/crate-ci/cargo-release

[1]: https://github.com/MarcoIeni/release-plz/discussions/1019

You should combine step 1 and 2 with CI. Just tag a version in your git, push to remote and have CI auto build a release for you.

Use github actions or other setup for other backends.

Or go nuts with cargo-release.

https://github.com/crate-ci/cargo-release

https://github.com/cargo-bins/release-pr

tools like cargo-release

Just to check, are you aware of cargo-edit's cargo-set-version or cargo-release?

I released my first crate that provides a derive macro to easily obtain a name of a current variant in an enum as a string. I did it mostly to learn about procedural macros and the process of releasing a crate. I then found out there is strum which does this and much more. Nonetheless, I learned a lot and I found couple of nice tools like ```cargo-release and git-cliff.

I'll note there is an issue in the cargo-release repo where this kind of workflow is wanted. https://github.com/crate-ci/cargo-release/issues/119

cargo-release is on about the same level of features used

cargo-release automates the release process for your crate. For example, with clap, all I do is add entries to the CHANGELOG and run cargo release patch and cargo-release takes care of updating files, publishing to crates.io, tagging, and pushing.

Yes, developers from all three tools were sharing ideas with each other recently