cargo-release
cargo-release
cargo-release | cargo-release | |
---|---|---|
1 | 11 | |
946 | 1,371 | |
- | 1.3% | |
10.0 | 9.0 | |
almost 2 years ago | 18 days ago | |
Rust | Rust | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
cargo-release
-
Rust 2030 Christmas list: Subcrate dependencies
Between workspace inheritance and tools like cargo-release, this has become trivial for me. If people don't want to use a third-party tool, we can always be working on improving cargo further, like publishing more than one crate at a time or merging support for modifying versions.
cargo-release
-
Changelog-Driven Releases
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
-
Oxlint – written in Rust – 50-100 Times Faster than ESLint
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
-
Rust 2030 Christmas list: Subcrate dependencies
tools like cargo-release
-
`toml` vs `toml_edit` (ie `toml` 0.6 is out)
Just to check, are you aware of cargo-edit's cargo-set-version or cargo-release?
-
What's everyone working on this week (45/2022)?
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.
- cargo-release v0.22 is out!
-
A GitHub Action for creating "Release PRs" for Cargo projects.
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
-
[Gitoxide December Update]: a new object database and upcoming multi-pack index support
cargo-release is on about the same level of features used
-
cargo-release v0.19
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.
-
Introducing `cargo smart-release` - the new way to release workspace crates
Yes, developers from all three tools were sharing ideas with each other recently