Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Process for config option stabilisation #3197

Closed
SimonSapin opened this issue Nov 12, 2018 · 4 comments · Fixed by #3486
Closed

Process for config option stabilisation #3197

SimonSapin opened this issue Nov 12, 2018 · 4 comments · Fixed by #3486
Labels
only-with-option requires a non-default option value to reproduce

Comments

@SimonSapin
Copy link

SimonSapin commented Nov 12, 2018

The trailing_semicolon configuration for example is currently unstable. What needs to happen in order for it to be stabilized?

(I would like to use it in a project that is otherwise compatible with the Stable channel.)

@nrc
Copy link
Member

nrc commented Nov 12, 2018

I don't plan on stabilising any more options before 1.0 (for the edition). After that I'd like to slowly stabilise options as we go along and think about a process for that. The main motivation will be the trade-off between implementation complexity and trying to minimise the overwhelming-ness of a huge number of options vs the utility of the option. I would also like to think about an overall strategy - do we want many small options or a smaller number of sweeping ones, or high level styles only.

@nrc nrc added the only-with-option requires a non-default option value to reproduce label Nov 12, 2018
@SimonSapin
Copy link
Author

To be clear, I don’t think there is much to discuss about this particular option. This is mostly about what is the process in general.

@SimonSapin
Copy link
Author

Hello @rust-lang/dev-tools team. Now that the 2018 edition and rustfmt 1.0 have shipped, what are your thoughts on the desired process for configuration option stabilization?

@scampi scampi changed the title Path to config stabilization? Process for config option stabilisation Mar 20, 2019
@scampi
Copy link
Contributor

scampi commented Mar 20, 2019

Just writing down some ideas for stabilising an option, comments welcome!

Conditions

  • 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

Steps for the stabilisation

Open a PR that closes the tracking issue:

  • update the Config enum marking the option as stable
  • update the the Configuration.md file marking the option as stable

Also do these actions:

After the stabilisation

Backward compatibility

The option should remain 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.
Maybe this is covered by the current version-gate scheme but I wanted to bring this aspect forward.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
only-with-option requires a non-default option value to reproduce
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants