Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doc: update stability index #943

Closed
wants to merge 1 commit into from
Closed

doc: update stability index #943

wants to merge 1 commit into from

Conversation

chrisdickinson
Copy link
Contributor

This simplifies the stability index to 4 levels:

0 - deprecated
1 - experimental / feature-flagged
2 - stable
3 - locked

Domains has been downgraded to deprecated, assert has been
downgraded to stable. Timers and Module remain locked. All
other APIs are now stable.

Fixes: #930

@@ -1,6 +1,6 @@
# Domain

Stability: 2 - Unstable
Stability: 0 - Deprecated
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not yet?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

By deprecated we mean "DON'T USE THIS!" :)

@mikeal
Copy link
Contributor

mikeal commented Feb 25, 2015

Should timers be locked? I think @piscisaureus is planning on doing some work there.

@mikeal
Copy link
Contributor

mikeal commented Feb 25, 2015

STABLE ALL THE THINGS!

+1 :)

@vkurchatkin
Copy link
Contributor

👍

Also #771

@cjihrig
Copy link
Contributor

cjihrig commented Feb 25, 2015

LGTM, pending the timers comment.

@chrisdickinson
Copy link
Contributor Author

@mikeal re: timers, IIRC the changes there will be perf improvements (which are allowed under the new "locked.") I think the changes were algorithm improvements for the timers + a better idle timeout system, but I am not 100% sure. If not, then we should back down from "locked" there.

I'll leave this open until tomorrow evening to get comments. If no one objects, I'll merge it in. Thanks!

@Fishrock123
Copy link
Member

👍

```

```
Stability: 3 - Stable
The API has proven satisfactory, but cleanup in the underlying
code may cause minor changes. Backwards-compatibility is guaranteed.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If "Backwards-compatibility is guaranteed." is removed, how can my npm modules declare which versions of the built-in modules like url and path they are compatible with?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See the above:

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's not even an answer to the only question in my comment.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The whole idea is that backwards compatibility is guaranteed by semver, stability levels don't really matter

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do I, as a module author, assert this semver in my package.json? There is no engines.iojs field I'm aware of.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is currently no mechanism for this outside of feature detection. A breaking change in a stable API must demonstrate enough value to justify the breakage – that bar is very high.

This simplifies the stability index to 4 levels:

0 - deprecated
1 - experimental / feature-flagged
2 - stable
3 - locked

Domains has been downgraded to deprecated, assert has been
downgraded to stable. Timers and Module remain locked. All
other APIs are now stable.

Fixes: #930
chrisdickinson added a commit that referenced this pull request Feb 27, 2015
This simplifies the stability index to 4 levels:

0 - deprecated
1 - experimental / feature-flagged
2 - stable
3 - locked

Domains has been downgraded to deprecated, assert has been
downgraded to stable. Timers and Module remain locked. All
other APIs are now stable.

PR-URL: #943
Fixes: #930
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Jeremiah Senkpiel <fishrock123@rocketmail.com>
Reviewed-By: Vladimir Kurchatkin <vladimir.kurchatkin@gmail.com>
@chrisdickinson
Copy link
Contributor Author

Merged in cf0306c.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants