When and why should features stop being experimental?

[mbovel]

When new features are added, they are generally first annotated as @experimental, until they are deemed "stable enough" to be included without flag.

During the last LAMP compiler meeting, we were wondering: what does "stable enough" mean? When can a feature be considered stable enough? And who makes that call? Do we need to have a clear process for this?

Another question was: should the compiler use the -experimental flag itself? The experimental documentation page says that "dependent projects also have to be experimental". If this is still true, we would probably not want that for the compiler.

What do you think?

[soronpo]

During the last LAMP compiler meeting, we were wondering: what does "stable enough" mean? When can a feature be considered stable enough? And who makes that call? Do we need to have a clear process for this?

We have such a process. It's called a SIP. Any language change must go through that. Standard library experimental currently do not have any equivalent process.

[kyouko-taiga]

Standard library experimental currently do not have any equivalent process.

I am not convinced that library changes should go through a similar process. Besides, the problem of perpetually experimental features applies to SIPs as well because there isn't really a mechanism to automatically trigger state transitions.

[kyouko-taiga]

My two cents on the subject is that the situation would likely improve if we made sure features are simply not allowed to remain perpetually experimental. We could say that the experimental bit can be set for at most X months and/or Y minor releases, after which the feature would have to either be merged, revised, or removed. That would mechanically trigger discussions about the relevance and overall "vibe" of a feature.

As for the second question: I think it is probably best to maintain status quo for two reasons:

• First, there's the very strong argument that we want Scala N to be able to compile Scala N+1 and if I'm not mistaken experimental features aren't really part of neither N nor N+1.
• Second, because IMO a compiler is a poor representative of the way a language is actually used in the wild, I think we should not make the mistake of taking our own experience with an experimental feature as "feedback" on its adequacy. If the goal of an experimental phase is to gather insights from the community we should make sure the community actually provided these insights.

[tgodzik]

My proposal (discussed also internally) would be to add a process:

1. With each minor release identify features that are experimental and we might want the to be stable.
2. Put those into an issue or a discussion a few days before a core meeting for people to comment if they want to.
3. On the core meeting for each feature decide if it can be made stable and if so what needs to be done for a feature to be stable. For smaller features and flags that do not change language behaviour we would not require an additional SiP. Anything bigger would need to go through SiP.
4. For selected features we give one minor time to address issues and come back to those on the next meeting.
5. For anything that already went through 4. or for things that did not require more work we announce them on Scala contributors to wait one final minor release.
6. If nothing breaking was reported we make a feature stable.

Ad. 3 We might need to invite additional people for some feature discussions.
Ad. 4 We don't want to select more features than possible to do within a span of one minor

If something needs a SiP approval we can do it during 5.

[tgodzik]

We've had a short discussion on the core meeting and we simplified the possible procedures.

1. First of all we should have a publicly available list of all experimental issues, which can be also announced for the community to check out.
2. Then we can have a quarterly (can be adjusted) meeting where we can pick features to become stable, anything not changing the language or accepted by sip can be made stable.
3. We vote on those on a core meeting.
4. Later we announce what will be picked as stable and update it as such in the next minor.

We can adjust the procedure if it turns out too complex or not complex enough.

[tgodzik]

The list will be worked on here, anyone can help out and maybe let me know where to look?