Marking new features as “Beta"

[zmerr]

Is your feature request related to a problem? Please describe.

After a new feature is added to a released in Metals, it takes some time for us to make sure it is working bug free.

Describe the solution you'd like

I think it is a good idea to be able to mark new features as Beta with a small sign added somewhere next to them for both warning the users that this is new and might have problems, and for hinting that they might consider reporting any bugs they find with the functioning of the new feature.

Another benefit is that, this would improve the confidence of users in the correct functioning of metals, by setting the right exceptions about the bug prone functionalities.

Describe alternatives you've considered

assuming that new features are bug free unless something is reported.

Additional context

Functionalities such as the adding or removal of braces, or map/flatMap to for comprehension conversion, are complicated with the worry that some special cases might not have been covered. Adding the beta flag to these features makes the users more careful when using such new features.

Search terms

beta labeling features

[tanishiking]

@zmerr Hey, thank you for raising the issue!
I personally don't think it''s a good solution to add Beta flag to Metals because

• We can use server version setting instead of Beta flag.
  • Beta flag is useful practice for products that provide one or two versions to end users, and enable users to switch between normal version and beta version.
  • However, users can switch versions (even nightly ones) of Metals.
• I believe unstable features shouldn't be released (though sometimes we unintentionally introduce bugs).
  • If Beta is more like experimental feature flag, I'm in.

As of flatMap to for comprehension code action, what do you think about adding "(beta)" to the title of code action?

[zmerr]

@tanishiking Thank you for sharing your thoughts.

Beta flag is useful practice for products that provide one or two versions to end users, and enable users to switch between normal version and beta version.

I have seen examples of just certain features getting flagged as Beta in other software products, instead of the whole release. what do you think of that one?

As of flatMap to for comprehension code action, what do you think about adding "(beta)" to the title of code action

Well, yes, I think that is a good idea. This way, the user would not just tap “switch to flatMap” and then later realize that the semantic of their code had been changed as a result.

[tanishiking]

My concern is like, release features under beta flags, and nobody uses it. I prefer to expose all features as much as possible (maybe with some cautions), and receive more feedback.

Yeah, I'm aware of softwares releases features under beta flag. I think they basically means "Please DO NOT use this one in production, that may wreck your whole environment".
In the future, Metals may need a beta flag for some features that may break users' environment (e.g. sbt's usePipeline, or Scala3's cc flag). But, I think it's not now (as we don't have such one in our release candidate).

In terms of the code action, users can safely switch back and forth by undo / redo, so I believe we don't need to hide them under beta flag :)

[zmerr]

@tanishiking

I prefer to expose all features as much as possible (maybe with some cautions), and receive more feedback.

hmmm…. that’s a thing🧐

[tgodzik]

Yeah, I'm aware of softwares releases features under beta flag. I think they basically means "Please DO NOT use this one in production, that may wreck your whole environment".

Yeah, I think we should not let the users think that something can break. We can add a note in the release notes to report any issues they see.