Use different versions of lib crate to enforce stability guarantee

[topecongiro]

Once #1583 gets resolved, we will be able to use different versions of the lib crate to enforce the stability guarantee.

I am thinking of something like the following:

In Cargo.toml, we add two versions of rustfmt-lib as dependencies

[dependencies.rustfmt_stable]
package = "rustfmt-lib"
version = "2.0.0"

[dependencies.rustfmt_nightly]
package = "rustfmt-lib"
version = "2.1.0"

and in rustfmt-bin, we call one of them depending on the configuration

if (config.Version >= Version::Two) {
    rustfmt_nightly::format()
} else {
    rustfmt_stable::format()
}

In the above example, we use 2.0.x as the stable releases and 2.y.z. as the nightly releases.

Pros and cons I am aware of:

• Pros
  • We get stronger stability guarantee.
  • We no longer need to add version gating to the develop branch
• Cons
  • We need to backport changes to the stable branch.
    • Updating rustc-ap-* crates
    • Fixing critical bugs
  • Stable users won’t be able to profit from improvements we make against the nightly branch unless we backport them.
  • We need to build two rustfmt-lib crates, which will likely lead to longer build time and larger binary

[scampi]

I think removing the version gating outweigh the 2 first cons.

[rchaser53]

I think it's a nice idea. But I have some questions.
Do you mean rustfmt_stable will not be added the new feature and only fix the bug until 3.0.0?
How about new syntax? Will rustfmt_stable be update to apply new syntax or bump up to 3.0.0?

[topecongiro]

Do you mean rustfmt_stable will not be added the new feature and only fix the bug until 3.0.0?

Basically yes, but we may backport some new important features if it does not require much work.

How about new syntax? Will rustfmt_stable be update to apply new syntax or bump up to 3.0.0?

We must use the same version of rustc-ap-* crates in both the stable and nightly rustfmt-lib crates, so yes, we will support the new syntax in the stable lib as well. With respect to the stable, every version update will be the patch update (e.g. 2.0.1 -> 2.0.2).

[otavio]

The maintenance burden will be huge and backporting might be difficult and involve a lot of conflict resolution. I am wondering, what use case this approach is trying to fulfill?

[topecongiro]

We will use a different schema for version management and stability enforcement. cc #4128.