This document outlines processes regarding management of rustfmt.
In this Section, we describe how to stabilise an option of the rustfmt's configration.
- Is the default value correct ?
- The design and implementation of the option are sound and clean.
- The option is well tested, both in unit tests and, optimally, in real usage.
- There is no open bug about the option that prevents its use.
Open a pull request that closes the tracking issue. The tracking issue is listed beside the option in Configurations.md
.
- Update the
Config
enum marking the option as stable. - Update the the
Configuration.md
file marking the option as stable. - Update
CHANGELOG.md
marking the option as stable.
The option should remain backward-compatible with previous parameters of the option. For instance, if the option is an enum enum Foo { Alice, Bob }
and the variant Foo::Bob
is removed/renamed, existing use of the Foo::Bob
variant should map to the new logic. Breaking changes can be applied under the condition they are version-gated.
For example, 1.0.0 -> 1.0.1:
-version = "1.0.0"
+version = "1.0.1"
E.g., https://github.com/rust-lang/rustfmt/commit/5274b49caa1a7db6ac10c76bf1a3d5710ccef569
git tag -s v1.2.3 -m "Release 1.2.3"
cargo publish
Note that if you are updating rustc-ap-*
crates, then you need to update every submodules in the rust-lang/rust repository that depend on the crates to use the same version of those.
As of 2019/05, there are two such crates: rls
and racer
(racer
depends on rustc-ap-syntax
and rls
depends on racer
, and rls
is one of submodules of the rust-lang/rust repository).