doc: additional clarifications to stability policy #22
Conversation
discuss nom, better handling of defaults, better treatment of post-ES5 feature introductions...
|
|
||
| When new features in the JavaScript language are introduced by V8, there will be a *semver-minor* version increase. TC39 has stated clearly that no backwards incompatible changes will be made to the language so it is appropriate to increase the *minor* rather than the *major*. | ||
|
|
||
| Pull Requests that introduce post-ES5 mechanisms into the Node.js Core Library API require TSC review and approval. If landed, such changes must result in a *semver-major* version increase. However, Pull Requests may introduce post-ES5 mechanisms into the *internal* JavaScript implementation of the Core Library API so long as those mechanisms do not "bleed out" through the API. | ||
| The Node.js Core Library API is currently built around ES5 Language features. While there are currently no plans to do so, it is possible for post-ES5 JavaScript language features to be introduced into the Core Library API in the future. If such changes can be introduced in a manner that is transparent to module and application developers and will not cause existing applications to break, the changes can be landed after sufficient review with either a *semver-patch* or *semver-minor* version increase (depending on whether the change introduces new APIs). However, if the changes cause a backwards incompatible change to the existing API or could cause existing modules and applications to break the change must be reviewed and approved by the TSC and must result in a *semver-major* version increase. |
There was a problem hiding this comment.
Better, but the semver-* language is a little unnecessary, since it is the same what applies to everything else.
It should be noted that ES6 features can be used internally. i.e. io.js already uses a good amount of const.
There was a problem hiding this comment.
I know it's a bit redundant. The idea is to err on the side of clarity. There's been quite a bit of contention on this between the two projects and I'd rather it be absolutely clear what it being decided on. We can refine the text later once we're sure there is consensus.
I removed the note about the use of ES6 features internally because of the "if it can be done transparently" comment. The stability policy is concerned primarily with the API so if adding ES6 features can be done without impacting API, it's not clear we need to include it here.
There was a problem hiding this comment.
FYI this isn't really true "The Node.js Core Library API is currently built around ES5 Language features" given iterable buffers etc.
doc: additional clarifications to stability policy
discuss npm, better handling of defaults, better treatment of post-ES5
feature introductions...