-
Notifications
You must be signed in to change notification settings - Fork 898
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
Comments
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. |
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. |
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? |
Just writing down some ideas for stabilising an option, comments welcome! Conditions
Steps for the stabilisationOpen a PR that closes the tracking issue:
Also do these actions:
After the stabilisationBackward compatibilityThe option should remain compatible with previous parameters of the option. For instance, if the option is an enum |
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.)
The text was updated successfully, but these errors were encountered: