docs(ref): Establish publish best practices #12745
Conversation
Inspired by rust-lang#841 and conversations at RustConf. At RustConf, someone was talking to me about the lack or inconsistent use of best practices within the crate ecosystem. We have a challenge of needing to help users get up and going who can't research every last decision while not over-encouraging the status quo, leading to stagnation. I do have a bias in this conversation as the maintainer of one of these tools which is why I decided to pick an ordering without judgement. I picked alphabetical ordering before sorting and realizing this puts my own crate first.
|
r? @ehuss (rustbot has picked a reviewer for you, use r? to override) |
rustbot
added
A-documenting-cargo-itself
src/doc/src/reference/publishing.md
Outdated
| > - [cargo-smart-release](https://crates.io/crates/cargo-smart-release) | ||
| > - [release-plz](https://crates.io/crates/release-plz) | ||
| > | ||
| > For more, see [crates.io](https://crates.io/search?q=cargo%20release) |
There was a problem hiding this comment.
| > For more, see [crates.io](https://crates.io/search?q=cargo%20release) | |
| > For more, see [crates.io](https://crates.io/search?q=cargo%20release). |
There was a problem hiding this comment.
I am not sure if "cargo release" is the correct keyword, but yet I can't see any better alternative 😆.
There was a problem hiding this comment.
Typo fixed.
Unsure how to make the search term any better. It seems to cover a lot of cases for command-line focused releases though that leaves out tools like release-plz. The release keyword isn't universally used and is too vague, covering a lot of other cases.
I've noted in the PR why I chose the crates I did. I think we'll need to handle it on a case-by-case basis though I expect a lot of cases to be obvious (brand-new tool that barely does anything is likely not something worth including). |
|
Thanks! @bors r+ |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
Update cargo 4 commits in e6aabe8b3fcf639be3a5bf68e77853bd7b3fa27d..59596f0f31a94fde48b5aa7e945cd0b7ceca9620 2023-09-26 16:31:53 +0000 to 2023-09-29 19:29:17 +0000 - refactor: Switch from termcolor to anstream (rust-lang/cargo#12751) - Add missing `strip` entries in `dev` and `release` profiles. (rust-lang/cargo#12748) - Add better suggestion for the unsupported silent flag (rust-lang/cargo#12723) - docs(ref): Establish publish best practices (rust-lang/cargo#12745) r? ghost
Update cargo 4 commits in e6aabe8b3fcf639be3a5bf68e77853bd7b3fa27d..59596f0f31a94fde48b5aa7e945cd0b7ceca9620 2023-09-26 16:31:53 +0000 to 2023-09-29 19:29:17 +0000 - refactor: Switch from termcolor to anstream (rust-lang/cargo#12751) - Add missing `strip` entries in `dev` and `release` profiles. (rust-lang/cargo#12748) - Add better suggestion for the unsupported silent flag (rust-lang/cargo#12723) - docs(ref): Establish publish best practices (rust-lang/cargo#12745) r? ghost
Inspired by #841 and conversations at RustConf.
At RustConf, someone was talking to me about the lack or inconsistent use of best practices within the crate ecosystem.
We have a challenge of needing to help users get up and going who can't research every last decision while not over-encouraging the status quo, leading to stagnation.
The list of tools included was based on a mixture of
I do have a bias in this conversation as the maintainer of one of these tools which is why I decided to pick an ordering without judgement. I picked alphabetical ordering before sorting and realizing this puts my own crate first.