Increase emphasis/visibility of version-specific nature on Config documentation

[calebcartwright]

rustfmt is a highly configurable formatter that supports various configuration options that allow users to override the default formatting rules (e.g. tabs instead of spaces). The set of supported configuration options, and their associated variants/stability/etc., is tightly associated to the corresponding rustfmt version.

For example, if a new configuration option foo_bar is added during the rustfmt v1.4.30 release, foo_bar is available in version v1.4.30, but foo_bar is of course not available in earlier versions of rustfmt (rustfmt v1.4.10 has no idea what foo_bar is).

As such, it's really important that when a user is browsing the rustfmt config documentation that they are looking at the version of the config docs that maps to the version of rustfmt they are actually using. Accordingly, the config documentation website has a dropdown field that allows users to select their corresponding version of rustfmt:

Unfortunately though, many users are unaware of the need to use the correct version and end up running into issues when they try to use a newer config option that isn't available in the rustfmt version they are actually using. We've tried a couple things to address this, such as adding this section to the file in source control which does appear a bit lower on the site for some versions, but we need to do more to make this obvious on the config site.

I'm open to any changes to the config site that makes it more visual and obvious, and helps users avoid these issues

[davidBar-On]

A possible enhancement may be to add the selected version number to the heading of each config option, e.g.:

Although that does not tell the users from which version the option is available, at least it may be more clear that the option documentation is for that specific version.

I am not submitting a PR with the change, as I am not sure if this approach is acceptable.

[calebcartwright]

Thanks for looking at this. I think the problem with that proposal is that it's going to be duplicative and still wouldn't itself convey the intent. I.e. folks either will already know the version relationship and this will just be noise, or they won't and still won't know what that text means.

The intent here is to loudly inform the uninformed user that configuration options can and do change from one version to the next, and users need to look at the right version of the docs

[davidBar-On]

What about adding a text to each option that is was not available at the first (documented) release or is not available in the last released version? Something like:

binop_separator_{(available from v1.2.4.26)}

or:

binop_separator_{(not released)}

The added text may be red or any other color to draw the user's intention.

At least the first approach may significantly increase the time of the initial page load, as it requires parsing all the versions documentations, but if it is desired then maybe it will be possible to do one time parsing for all and prepare a file with the first version for each configuration option.