timers: unlock the timers API

[Trott]

Change the Stability Index on timers from Locked to Stable.

Note that this is not intended to encourage changes to the timers API,
but to allow it when its useful for Node.js (as has happened in
violation of the documented stability level), and possibly to simplify
the stability levels by removing Locked altogether.

Refs: #11200

@nodejs/ctc

Checklist

• documentation is changed or added
• commit message follows commit guidelines

Affected core subsystem(s)

timers

[Fishrock123]

+1 if we are removing locked, -1 otherwise? I can't forsee a good reason to do this and there has not been any significant requests, language features or otherwise, to do so?

[gibfahn]

+1 if we are removing locked, -1 otherwise?

I assume the easiest way to remove Locked would be to first remove everything that's currently marked as Locked (i.e. a case-by-case analysis of whether there's a good reason for each module to be Locked rather than Stable). If we've done that then it's an easy decision to remove the category entirely.

I'd say in this case that having it be Locked doesn't add anything, so +1 as a step towards removing Locked.

[ChALkeR]

+1

[jasnell]

I would love to see us simplify the stability matrix by dropping locked.

[Trott]

+1 if we are removing locked

That's the plan...

[Fishrock123]

I'd say in this case that having it be Locked doesn't add anything, so +1 as a step towards removing Locked.

Not sure I agree. The intention here (as far as I can tell) was to pretty much never add public APIs to timers. I suppose that is to say, we follow browsers quite close for this module and since they don't have things besides setTimeout() and setInterval() we avoid having anything else too. (There is of course the exception for setImmediate() coming from the now years-old change to process.nextTick().

[gibfahn]

The intention here was to pretty much never add public APIs to timers

I get the intention, but for me the difference between Locked and Stable is the pretty much in that sentence. Given that changes have and will be made (possibly in the future due to changes in ecma262), as detailed in #6528 and #11200, it doesn't seem correct to call these modules Locked.

For example, if Timers is locked, then we shouldn't really accept #11384 right? The locked definition doesn't say no new APIs, it says no changes to APIs.

Stability: 3 - Locked
Only bug fixes, security fixes, and performance improvements will be accepted.
Please do not suggest API changes in this area; they will be refused.

I think we should be resistant to (or very careful about) adding new public APIs to any of the Stable modules without clear justification. I just don't see what Locked adds here if it's not really Locked.

Stability: 2 - Stable 
The API has proven satisfactory. Compatibility with the npm ecosystem 
is a high priority, and will not be broken unless absolutely necessary.

[ChALkeR]

/cc @nodejs/ctc for additional review, as this might be controversial (I'm +1 though).

[Trott]

Landed in c76f737

[Fishrock123]

I'm still -1 on this unless we are removing Locked entirely and that is not clear to me yet. 😞

[ChALkeR]

@Fishrock123 #11661 removes Locked entirely and has 7 LGTMs and no objections atm.