Experimental Features Strategy

[rubo-21]

I would like to discuss a bit how experimental features are implemented and treated.

Let's first remember how is the situation now. Experimental features being added to main (and only) release and getting shipped to everyone. I see one 'problem' here which I would like to raise. The problem is that people really don't understand is it a real experimental thing or its feature which most probably will be added as stable. To deep dive into the root of this problem I want to add a bit history here. So back then when ES6-7 stuff invented and everybody was curious about new features of ECMAscript and wanted to test/use them as soon as possible they had to use special flag because features were added as 'experimental'. A lot of people even run apps with flags on production trying to get that functionality as soon as possible. Time have passed and now luckily we have that functionality without flag or anything. But it Taught us to do a 'bad thing'. It changed people's mind about experimental features. They started thinking that it's not that 'experimental' and we got that new bad habit. Which is using experimental features in real world applications and even on production. We have same situation with worker threads and other features. So there is a misunderstanding of concept of experimental features. Community used to use experimental features and we already have that bad habit and we continue doing it wrong. In my opinion experimental features should not be used at all as they are experimental and you have no guarantee that they would be upgraded as stable or removed. Or you will have the same API as you have on current version.

I think we need a bit clarity here. A way to determine is the feature really experimental or not. I see 2 possible solutions here which can make situation better.

1. Have separate build/release like beta/canary/nightly build which will include all new experimental things and main stable release won't. So people will not use it on production but only for some tests. I see only one reason to not split builds because it will make maintenance harder but I think it worths the effort.

2. So the second solution is to have level of experiments which will determine how experimental that is. like 3 levels low. medium and critical.

• low - If experiment level is low it means that its something which most probably will be added and will not be changed that much
• medium - will throw a warning which says that this is experimental and not likely to be used on production or real project
• critical - will throw and exception saying "hey you're using an experimental feature which is not stable yet, please consider not using it or using alternative feature" and will end the process. Critical experiments would be running only lets say with special flag or env var or something so user will know that this is experimental and this is kind of one time thing you are just running this to play with it and that's it.

I would love to have your thoughts on this, maybe a better way to solve this or something.
Thanks for your attention.

[rubo-21]

CC: @ryzokuken

[devsnek]

possible duplicate of #22021?

[ryzokuken]

@devsnek I think this is more about discussing how experimental features work and revisiting if it's the best possible strategy in the first place, but I might be wrong.

Labelling this as "meta" for now.

[devsnek]

the issue says experimental flags but discusses js features, which would be harmony flags (and not under the control of node). are we talking about node's experimental flags, or v8's experimental flags? both?

[rubo-21]

@ryzokuken is absolutely right. @devsnek So ES6-7 features were under flag on v8? Anyway it was just an example. So what am saying is to rethink how we ship and treat experimental features. And I suggested 2 possible solutions.

[BethGriggs]

I think the discussion Proposal: Subdivide “Experimental” Status and the resulting PR #46100 go some way to addressing the points raised here and implement a similar solution to what @rubo-21 suggested.

As this issue is fairly old, I'm going to close, but encourage any further comments or feedback to be added to the recent discussion thread. Thanks, @rubo-21.