docs: lower the maximum stability level to "stable"

[jonathanong]

personally never liked "frozen" or "locked" stability levels. although it makes sense from a maintainer's perspective, it somewhat alienates the community. i'd rather have maintainers destroy feature requests with reasoning instead of "the API is locked. this issue is closed". instead, i want the community to actively suggest ways to make iojs better, regardless of how much change it may introduce.

I also do not believe these stability levels to be true.

• assert is probably going to change with assert: check object prototype in deepEqual #621
• with es6, modules are very likely to change (though we have no idea yet)
• timers have changed (in functionality, not necessarily API) almost every minor version of node/iojs
• .getMaxListeners() was recently added to events

[cjihrig]

Nice branch name :-)

[brendanashworth]

👍 from me, but I'd even go as far as removing the stability levels entirely. I don't think warnings like "Backwards-compatibility will be maintained if reasonable" and "may change or be removed in future versions" are pertinent anymore now that we've moved to semver.

Plus, I'd say modules like crypto (but not tls?), cluster, and stream are pretty far from "unstable" and "insufficient real-world testing".

[bnoordhuis]

Playing Devil's advocate: one counterargument is that 'frozen' makes it clear that pull requests are not welcome, however well-intentioned the feature. It preempts a lot of mostly unproductive discussion.

[Fishrock123]

Looks like @jonathanong beat me to it.

I am -1 on the notion or idea of locked / frozen APIs. I feel they hider worthwhile progress.

I remember seeing a few quality-of-life improvements to locked / frozen in node over the last year or so be rejected only because the API is frozen / locked.

[chrisdickinson]

I'm kind of loathe to drop the "locked" / "frozen" stability levels. The answer for "why can't we change them" is almost always because it's easy for unintentional consequences to break user code badly. Even if they're not 100% true all of the time (what things are, in programming?) they convey the severity of changing those APIs very well.

That said, in the past we've talked about "ratcheting" up APIs to frozen/locked over time – which implies that the ultimate goal of any API is to eventually be locked. I disagree with that approach.

Re: modules: the modules likely won't change, but a new system may land adjacent to the existing module loader. We can't eliminate require as soon as the import syntax lands.

Re: events: that points more at changing the definition of "locked" than getting rid of the concept entirely – maybe "locked" means "non-security-related backwards incompatible changes will not be accepted."

[jonathanong]

i'd rather replace frozen with "really fucking stable"

[Fishrock123]

stability level changes-may-have-drastic-consequences

[vkurchatkin]

@jonathanong frozen is actually quite a good movie. that said, it would be hard to explain changes in "frozen" api. +1. stable is enough

[reqshark]

+1 Change it to RFS

[Qard]

To be fair, despite the "frozen" labels, there's been several promisification PRs. I don't think "frozen" really says "we're never changing this, ever" but more "if we change this, there will be some very serious review first".

[Fishrock123]

I don't think "frozen" really says "we're never changing this, ever" but more "if we change this, there will be some very serious review first".

then "Frozen" and "Locked" are still the wrong words. :)

[Qard]

You can thaw that which is frozen, and unlock that which is locked.

[rvagg]

removed tc-agenda label for now, TC decided to push this discussion back a few weeks at least so we'll leave this issue open as a reminder eh? see #699

[Fishrock123]

@jonathanong are you satisfied with the changes in cf0306c?

[jonathanong]

👍