I don't do automated changelogs or versioning but it also makes it faster for me to do so.

I really dislike focusing on issue ids. I only want to jump to another tool if I need more information, so put it in the footer for after I've read what is there, like a front page news article giving you the option to go to the back to read more. Worst case that I've seen is people that think the Issue ID is all you need.

- Our compatibility guarantees mean we can't fundamentally change `cargo update`

- Using the third-party package name of `cargo upgrade` would be confusing in the distinction between the two

- We have to be very careful adding the mode to the existing command

I also appreciate the ordering. In my projects, we put an extra focus on tests by having having a commit that adds new tests to reproduce the bad behavior so when you diff the tests with the fix commit, you get a visual of how things changed.

I also find that the order can be PR specific. I wonder about allowing the contributor or reviewrs reorder on per-PR basis.

There are also times we have a lot of test or doc changes. I wonder about grouping items to jump between or collapsing to more easily navigate around than opening and browsing a file picker.

- splitting up a package into smaller compilation units to speed up builds as llvm doesn't like large compilation units, e.g. I'm assuming this is why uv is split up

- splitting semver concerns (easiest if different parts of the api are versioned independently), e.g. one hope for splitting out `serde_core` is to allow breaking changes of `serde_derive`

- splitting out optional parts to improve build time (`features` can also be used but usability isn't as great), e.g. `clap` (cli parser) and `clap_complete` (completion support)

- local development tools, e.g. https://github.com/matklad/cargo-xtask

- less commonly run tests or benches that have expensive dependencies, e.g. `toml` splits out a benchmark package for comparing performance of `toml`, `toml_edit`, an old version of `toml`, and `serde_json`

- proc-macros generally have a regular library they generate code against

- lower development overhead to develop them together, e.g. anstyle has a lot of related packages and I wouldn't be wanting to maintain a repo per package

Packages also let you mix a library with bins and examples. We talked about multi-purpose packages vs libraries at https://blog.rust-lang.org/inside-rust/2024/02/13/this-devel... (this was before workspace publishing was supported).

Something this doesn't mention is that Cargo workspaces allow for sharing parts of the manifest through "workspace inheritance", including package metadata like the repo, dependency version requirements, lint configuration, or compilation profiles.

Unfortunately, some markdown implementations don't handle this well. We were looking at using code-fence like syntax in Rust and we were worried about people knowing how to embed it in markdown code fences but bad implementations was the ultimate deal breaker. We switched to `---` instead, making basic cases look like yaml stream separators which are used for frontmatter.

Maintainer of Winnow here. I wish there were more details on this. I switched `toml` / `toml_edit` to being hand written and got some performance boost but I feel like the other things listed would have dwarfed the gains that I got. I wonder if there were sub optimal patterns they employeed that we could find ways to help better guide people.

For anyone going on about "hand written is always better", I disagree. Parser combinators offer a great way to map things back to grammar definitions which makes them much easier to maintainer. Only in extreme circumstances of features and/or performance does it seem worth going hand-written to me.

- completions being aware of the subcommand

- dynamic look ups for specific values

- completions being aware of previous options, flags, and values

A lot of completions have the first. Some have the second. The last is rare. The completer needs knowledge of when flags, options, and value can be repeated and change which future options and values are suggested.

If that is correct, I thought this was discussed when Trusted Publishing was proposed for Rust that it was not meant to replace local publishing, only harden CI publishing.

https://c3-lang.org/language-overview/examples/#enum-and-swi...

> But the whole point of thiserror style errors is to make the errors part of your public API. This is no different to having a normal struct (not error related) as part of your public API is it?

Likely you should use private fields with public accessors so you can evolve it.

- Struct variant fields are public, limiting how you evolve the fields and types

- Struct variants need non_exhaustive

- It shows using `from` on an error. What happens if you want to include more context? Or change your impl which can change the source error type

None of this is syntactically unique to errors. This becomes people's first thought of what to do and libraries like thiserror make it easy and showcase it in their docs.

I also feel thiserror encourages a public error enum which to me is an anti-pattern as they are usually tied to your implementation and hard to add context, especially if you have a variants for other error types.

Would love built in coverage support but investigation is needed on the design (https://github.com/rust-lang/cargo/issues/13040) and we likely need to redo how we handle doctests (https://blog.rust-lang.org/inside-rust/2025/10/01/this-devel...).

- synchronization operations are implicit so we need to re-resolve to confirm the lockfile is still valid. We could take some short cut but it would require re-implementing some logic

- dependency resolution only uses `Cargo.toml` for local and git dependencies. Registry dependencies have a json summary of what content is relevant for dependency resolution. Cargo parses nearly every locked package's `Cargo.toml` to know how to build it.