diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..1c69c1f --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +lts.md diff --git a/README.md b/README.md index 1ee52a3..80f4096 100644 --- a/README.md +++ b/README.md @@ -18,6 +18,38 @@ This document is a work in progress draft of a *proposed* development and releas Nothing within this document should currently be considered final. +## Repository Reconciliation Plan + +There are currently release lines in both node.js and io.js. Starting at the point from which io.js was created, the two repositories have diverged significantly. Bringing the two repositories back together under the Foundation TSC will not happen immediately. + +``` + now + (io.js) v1.6 : v1.7 v1.x + | | : | | + v0.10.x /--------------:-----------------\ Node.js 2.0 +____|____/ : \______|_____ + \ : / + \--------------:-----------------/ + | | : | | + (node.js) v0.12.x : v0.13.x v0.14.x +``` + +At the time of this writing, the current Node.js release is v0.12.2. The current io.js release is 1.7.1. + +Upon Foundation launch, both projects will come together under a single TSC, but the two distinct release lines will continue independently for the near term. Each subsequent release ("interim releases") for each project should incrementally bring the two code bases closer together, allowing them to eventually merge back into a single Node.js 2.0 release line. + +To avoid introducing unnecessary problems for users, the interim releases should not overlap versions. All prior versions of both io.js and node.js should be preserved. The interim Node.js releases will remain the v0.x version stream. Interim io.js releases will continue to follow their existing semver strategy. If Interim changes in io.js require a major version bump to 2.x, the first release of the Converged Project would be the next major version number (3.0). The Converged Project will use semver for release versioning. + +For purposes of managing each separate release line, if the TSC determines it to be necessary, the TSC can charter an io.js Working Group and a node.js Working Group, each responsible for their own respective release lines. + +To facilitate and oversee the convergence of the release lines, the TSC will charter a Convergence Working Group. This WG would ensure that appropriate steps are being made in each of the two release lines to bring the projects back together. The Convergence WG would work directly with both release line WG’s. As soon as the release lines converge, the charters for the separate release line WG’s and the convergence WG would expire, and responsibility for the continued evolution of the converged release line would be with the project TSC itself. The initial membership of the Convergence WG will be a subset of members from each of the two release line WG’s. + +For the Converged Project, a new Github organization owned and managed by the Node.js Foundation would be created. Once the new Github organization is established, ownership of the existing iojs/io.js and joyent/node repositories should be transferred. From there, the Convergence WG will be responsible for determining the exact next steps for creating the Converged repository. Additional repositories from each of the existing joyent/* and iojs/* organizations may need to be transferred to the Node.js Foundation organization as well. + +The Converged repository must contain maintenance branches for all prior stable lines from both release lines. + +Note: The specific details for how the organization would be created (e.g. if it would be a brand new organization or a migration of one or both of the existing organizations) has yet to be determined. This is a complex issue that will require careful thought. It will be the responsibility of the Convergence WG to determine the specific details. + ## Contributing ### Collaborators @@ -56,20 +88,6 @@ All Pull Requests that either fix bugs or introduce new functionality require at Pull Requests for changes intended to improve performance require a benchmark demonstrating the performance impact. The benchmark should demonstrate improved performance after the change is applied. -### Branching Model - -The Project source repository will be organized into a single *master* branch, multiple Release branches, and multiple Development Branches. All modifications intended for the current major release line must be made to the *master* branch and must follow the guidelines detailed in this document. Modifications to Release branches are limited to bug fixes, with priority given to changes that address specific security vulnerabilities. Oversight of the Release branches belongs to the Long Term Support (LTS) Working Group. The LTS Working Group will establish policies for landing Pull Requests into Release branches. - -``` - (dev branches) (dev branches) - / / \ \ / / \ \ - ---------------------------------------------------------------> master - \ \ \ \ \ \ - x.0 x.1 x.2 x+1.0 x+1.1 x+1.2 (releases) - -``` - - ### Landing Pull Requests When Landing a Pull Request, a Collaborator must modify the original commit message to include the following additional meta information regarding the change process: @@ -99,17 +117,37 @@ The *tsc-agenda* tag is used to elevate items to the next TSC meeting. TSC meeti Every Working Group must specify a tag that can be used to indicate items for review by the Working Group and a tag that can be used to identify Working Group meeting notes and announcements. -## Release Process +## Release Process and Branching Model + +The Project source repository will be organized into a single `master` branch, multiple maintenance branches, and multiple development branches. All modifications intended for the current major release line must be made to the `master` branch and must follow the guidelines detailed in this document. + +At each new *semver-patch*, a Release tag is cut (e.g. `v2.0.0`, `v2.0.1`, `v2.1.0`, etc). -### Release Branches +``` + (dev branches) (dev branches) + ⇗ ⇗ ⇘ ⇘ ⇗ ⇗ ⇘ ⇘ + -----------------------------------------------------------------> master + ⇣ ⇣ ⇣ ⇣ ⇣ ⇣ + tag:v2.0.0 tag:v2.1.0 tag:v2.2.0 tag:v3.0.0 tag:v3.1.0 tag:v3.2.0 (releases) + +``` + +Before a new *semver-major*, `master` is branched for maintenance of the prior major (e.g. `v1.x`, `v2.x`). + +``` + v2.x ------> maintenance + ⇗ + -------------------------------------------------> master + ⇣ ⇣ ⇣ ⇣ + tag:v2.0.0 tag:v2.1.0 tag:v2.2.0 tag:v3.0.0 -The *master* branch is the current major release branch. Most Pull Requests are sent to this branch and it is the default repo branch. +``` -Before a new major release, master is branched for LTS releases of the prior major. Example: `1.x`, `2.x`. These become the "head" of the LTS release and are where Pull Requests addressing bugs in the branched stream are to be landed. +Modifications to maintenance branches are limited to bug fixes, with priority given to changes that address specific security vulnerabilities. Oversight of the maintenance branches belongs to the Long Term Support (LTS) Working Group. The LTS Working Group will establish policies for landing Pull Requests into maintenance branches. -Additionally there are branches for stable release lines prior to 1.0 of minor versions. Example: `0.8.x`, `0.10.x`, `0.12.x`. +The LTS Working Group may choose to utilize it's own tags to identify LTS Release Candidates and LTS Releases and can choose to create additional maintenance branches if need arises. The LTS Working Group may also choose to utilize extended version metadata for tracking changes that land within maintenance branches. -All Release Branches other than master are managed by the LTS Working Group and fall under the LTS release policy. +Additionally there are branches for stable release lines prior to 1.0 of minor versions. Example: `v0.8.x`, `v0.10.x`, `v0.12.x`. During the interim period between the launch of the Foundation and the convergence of the two release lines, variations may exist in the specific release cycles for the Node.js v0.x stream and the io.js 1.x stream. These variations are allowed to aid in the transition process. @@ -127,10 +165,6 @@ Minors are the addition and refinements of APIs or subsystems. They do not chang Majors contain changes in behavior that could potentially break code that worked in prior releases. -#### Post-Release Metadata - -LTS Releases are tagged with additional `~Major.Minor.Patch` metadata used to track post-release modifications to the LTS Release. LTS Candidates are tagged with additional '-rc.x' metadata where the `x` indicates a specific Candidate number. This additional metadata is managed solely by the LTS WG. Every new LTS Release is automatically tagged with the extension `~0.0.0` to indicate it's status as an LTS Release (Note: this replaces the current convention of using the `-release` extension to flag releases) - ### Release Process for Master Releases should not contain too many code changes and if the rate of code changes is high then it should correspond to an increase in the rate of releases. It is expected that there should be about one release per week. @@ -139,113 +173,14 @@ Master must pass a full CI test run prior to release. If master contains changes which are tagged *semver-minor* then the release should bump the minor version otherwise it is a patch release. -## Repository Reconciliation Plan +## Long Term Support Working Group Roadmap -There are currently release lines in both node.js and io.js. Starting at the point from which io.js was created, the two repositories have diverged significantly. Bringing the two repositories back together under the Foundation TSC will not happen immediately. - -``` - now - (io.js) v1.6 : v1.7 v1.x - | | : | | - v0.10.x /--------------:-----------------\ Node.js 2.0 -____|____/ : \______|_____ - \ : / - \--------------:-----------------/ - | | : | | - (node.js) v0.12.x : v0.13.x v0.14.x -``` - -At the time of this writing, the current Node.js release is v0.12.2. The current io.js release is 1.6.4. - -Upon Foundation launch, both projects will come together under a single TSC, but the two distinct release lines will continue independently for the near term. Each subsequent release ("interim releases") for each project should incrementally bring the two code bases closer together, allowing them to eventually merge back into a single Node.js 2.0 release line. For purposes of managing each separate release line, the TSC will charter an io.js WG and a node.js WG, each responsible for their respective release lines. The membership for each release line WG will be the current membership of each of the two separate projects TSC’s. - -To avoid introducing unnecessary problems for users, the interim releases should not overlap versions. All prior versions of both io.js and node.js should be preserved. The interim Node.js releases will remain the v0.x version stream. Interim io.js releases will continue to follow their existing semver strategy. If Interim changes in io.js require a major version bump to 2.x, the first release of the Converged Project would be the next major version number (3.0). The Converged Project will use semver for release versioning. - -To facilitate and oversee the Convergence effort, the TSC will charter a Convergence Work Group. This WG will ensure that appropriate steps are being made in each of the two release lines to bring the projects back together. The Convergence WG will work directly with both release line WG’s. As soon as the release lines converge, the charters for the separate release line WG’s and the convergence WG will expire, and responsibility for the continued evolution of the converged release line will be with the project TSC itself. The initial membership of the Convergence WG will be a subset of members from each of the two release line WG’s. - -For the Converged Project, a new Github organization owned and managed by the Node.js Foundation will be created. Once the new Github organization is established, ownership of the existing iojs/io.js and joyent/node repositories should be transferred. From there, the Convergence WG will be responsible for determining the exact next steps for creating the Converged repository. Additional repositories from each of the existing joyent/* and iojs/* organizations may need to be transferred to the Node.js Foundation organization as well. - -The Converged repository must contain release branches for all prior stable lines from both release lines. - -Note: The specific details for how the organization will be created (e.g. if it would be a brand new organization or a migration of one or both of the existing organizations) has yet to be determined. This is a complex issue that will require careful thought. It will be the responsibility of the Convergence WG to determine the specific details. - -## Long Term Support - -All Releases branches automatically shift into the responsibility of the Long Term Support working group. Determination of the LTS strategy for specific releases the responsibility of the LTS WG. - -The LTS WG is expected to establish a regular and predictable cadence of stable releases. To this end, the LTS WG must maintain and regularly publish a clear Roadmap that outlines the priorities and milestones for upcoming LTS Releases. The goal of the Roadmap is to help guide the project's evolution as opposed to constraining it. - -### Strawman LTS Strategy: - -Note: this is a strawman meant to stimulate discussion. Feel free to knock it down. See https://github.com/jasnell/dev-policy/issues/15 and https://github.com/jasnell/dev-policy/issues/26 for additional discussion. - -The *master* branch must always be in a production-ready state. Features landed must be complete and functional. - -Every Release Branch creates an opportunity to establish a new Long Term Support release. For instance, suppose the master branch rolls to version `2.0.0`. The LTS WG can decide in advance that there will be an LTS release in the `2.0.x` stream. At any point, the LTS WG can declare any version within that stream to be an "LTS Candidate" by cutting a `2.0.x-rc.1` tag where `x` is the current patch level. Sufficient time should then be given to allow the tag to be reviewed and tested. If things look good, the `2.0.x` version becomes the LTS Release. If, after testing, it becomes apparent that additional patches or even minor bumps become necessary, the LTS Candidate can be shifted and new `2.y.x-rc.2` tag created where `y` is the current minor and `x` is the current patch. LTS Releases are identified by appending a `~0.0.0` to the version (i.e. `2.5.3~0.0.0`). This additional metadata identifies the post-release semantic versioning extension for the LTS release. - -Once the `-rc.1` tag is cut at a particular point, the master stream goes into "Feature Freeze" until the release branch is cut. New features landed before the `-rc.1` tag make it into the LTS Release, those that do not must wait to land until after the Feature Freeze is lifted. - -Example: -* LTS WG declares that there will be an LTS Release in the 2.0.x stream. -* Major version rolls over to 2.0.0 -* 2.0.0 is tagged as 2.0.0-rc.1, Feature Freeze on master begins -* Several Patches on 2.0.x occur such that the current version is 2.0.10 -* The LTS WG feels that 2.0.10 is stable so it cuts the 2.0.10-rc.2 tag. -* Additional testing shows no significant issues with 2.0.10-rc.2 so 2.0.10 is declared to be the LTS Release. -* The 2.0.10~0.0.0 branch is created off 2.0.10, Feature Freeze on master is lifted. -* Later on, bugs are discovered in the LTS branch that need to be fixed. A Minor bump and several Patches are commited making the updated LTS version 2.0.10~0.1.5 - -``` - +----------------------------------+ - | LTS feature freeze | - -------------------------------------------------------> master - \ .......................... \ - 2.0.0 2.0.10 -----------------> (LTS stream) - | | \ \ - | | ~0.0.0 ~x.y.z - tag:2.0.10-rc.1 tag:2.0.10-rc.2 -``` - -Example: -* LTS WG declares that there will be an LTS Release in the 2.5.x stream. -* Major+Minor version rolls over to 2.5.0 -* 2.5.0 is tagged as tag:2.5.0-rc.1, Feature Freeze on master begins -* Several Patches on 2.5.x occur such that the current version is 2.5.6 -* A PR comes in that would roll a Minor version increase to 2.6.0, -* The LTS WG decides to include the Minor increase in the LTS so that 2.6.x becomes the new LTS Candidate -* 2.6.0 is tagged as 2.6.0-rc.2 -* A couple additional patches come in and the LTS WG feels that 2.6.2 is stable enough to cut the 2.6.2-rc.3 tag. -* Additional testing shows no significant issues with 2.6.2-rc.3 so 2.6.2 is declared to be the LTS Release. -* The 2.6.2~0.0.0 branch is created off 2.6.2, Feature Freeze on master is lifted. -* Later on, a major security vulnerability in the LTS branch is discovered. The fix requires a backwards compatible breaking change in, forcing a Major bump in the Post release metadata. The 2.6.2~1.0.0 tag is created to reflect the change. - -``` - +------------------------------------------+ - | LTS feature freeze | - -------------------------------------------------------> master - \ ............ \ ....... \ ......... \ - 2.5.0 2.5.6 2.6.0 2.6.2 ---------> (LTS stream) - | | | \ \ - tag:2.5.0-rc.1 tag:2.6.2-rc.2 | ~0.0.0 ~1.0.0 - tag:2.6.2-rc.3 -``` - -The goal here is to allow LTS Releases to be cut organically without adversely impacting the overall flow of commits into master. The additional patch metadata, while admittedly annoying, allows the LTS WG to work independently of the primary versioning scheme in master, allowing LTS releases to be cut at any time and even allowing multiple LTS releases within a single Major.Minor stream if necessary. The LTS WG could even decide to skip Major version bumps entirely if necessary. +The LTS WG is expected to establish a regular and predictable cadence of LTS Releases. To this end, the LTS WG must maintain and regularly publish a clear Roadmap that outlines the priorities and milestones for upcoming LTS Releases. The goal of the Roadmap is to help guide the project's evolution as opposed to constraining it. ## Issues Workflow The tracking and management of issues is still an open discussion. See https://github.com/jasnell/dev-policy/issues/9 and https://github.com/jasnell/dev-policy/issues/8 -## Developer's Certificate of Origin 1.0 - -By making a contribution to this project, I certify that: - -(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or - -(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or - -(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. - ## Stability Policy The most important consideration in every code change is the impact it will have, positive or negative, on the ecosystem (modules and applications). To this end, all Collaborators must work collectively to ensure that changes do not needlessly break backwards compatibility, introduce performance or functional regressions, or negatively impact the usability of the Project on any of the platforms officially targeted for support by the Project. The TSC is responsible for determining the list of supported platforms. @@ -280,7 +215,7 @@ When discussing stability, it is important to first review Node.js' layered arch +---------------------------------------+ ``` -Node.js currently builds on top of several key dependencies including the V8 JavaScript engine, libuv, openssl and others. The Node.js Application Binary Interface provides critical functionality such as the Event Loop which critical to how Node.js operates. The Node.js Core Library is the primary interface through which most Modules and Applications built on top of Node perform I/O operations, manipulate data, access the network, etc. Some modules and applications, however, go beyond the Core Library and bind directly to the Application Binary Interface and dependencies to perform more advanced operations. The Binary abstraction layer is used to buffer module and application developers from changes in the Application Binary Interface and Dependencies. +Node.js currently builds on top of several key dependencies including the V8 JavaScript engine, libuv, openssl and others. The Node.js Application Binary Interface provides access to functionality central to how Node.js operates. The Node.js Core Library is the primary interface through which most Modules and Applications built on top of Node perform I/O operations, manipulate data, access the network, etc. Some modules and applications choose to go beyond the Core Library and bind directly to the Application Binary Interface and dependencies to perform more advanced operations. An optional Binary abstraction layer is used to buffer module and application developers from changes in the Application Binary Interface and Dependencies. Due to the existing layering, modules and applications are sensitive not only to changes in the Core Library API, but the Application Binary Interface and dependendencies as well. @@ -290,7 +225,7 @@ Any *backwards incompatible* change to either the Node.js Core Library API or Ap Any Modification to the ABI, dependencies or Native abstractions that require a developer to *modify code* and then recompile is considered a backwards incompatible change that must result in a *semver-major* version increase. -Reversions of any changes landed into *master* are to be handled just like any other type of pre- or post-release modification. +Reversions of any changes landed into `master` are to be handled just like any other type of pre- or post-release modification. ### Implicit vs. Explicit API Stability @@ -316,27 +251,31 @@ Backwards incompatible changes to *Implicit* APIs that have been included in a R That said, changes to any of the APIs should not be made lightly as there is currently no reliable means of determining in advance the impact any change may have on existing applications and modules. Collaborators must use their best judgement to determine whether any given change is "technically backwards incompatible but in practice should not be", then approach landing the change accordingly. -There should never be any API change in an LTS Release unless the change is required to address a critical security vulnerability. +There should never be any API change in a maintenance branch unless the change is required to address a critical security vulnerability. ### Platform Stability -The Platforms supported by the Node.js project are generally divided into four distinct categories: *Primary*, *Secondary*, *Experimental* and *Deprecated*. +The Platforms supported by the Node.js project are generally divided into three distinct categories: *Supported*, *Experimental* and *Deprecated*. -*Primary* Platforms consist of those supported in LTS Releases. These are the Platforms on which Node.js must not break and for which subsequent LTS Releases must be fully operational with no regressions. +*Supported* platforms consist of those with support in the `master` branch. For every release, the build must complete successfully and pass a full CI test run on every *Supported* platform. -*Secondary* Platforms consist of those with support in the master branch but have not yet been included in an LTS Release. +*Experimental* Platforms consist of those for which there is active ongoing development to port Node.js to the platform but functionality may not yet be feature complete or fully operational. Support for experimental platforms may not yet have been committed to `master` and might be done in a Development branch or separate repository entirely. -*Experimental* Platforms consist of those for which there is active ongoing development to port Node.js to the platform but functionality may not yet be feature complete or fully operational. Support for experimental platforms may not yet have been committed to *master* and might be done in a Development branch or separate repository entirely. The goal for Experimental Platforms would be for them to eventually graduate to *Secondary* Platforms. +*Supported* and *Experimental* Platforms remain active so long as there are Collaborators actively maintaining support for them. -*Secondary* and *Experimental* Platforms remain active so long as there are Collaborators actively maintaining support for them. +*Deprecated* Platforms consist of platforms for which: (a) there is no active development, (b) there are no Collaborators actively maintaining support, or (c) it is no longer feasible or practical to continue supporting. -*Deprecated* Platforms consist of prior *Primary*, *Secondary* or *Experimental* Platforms that are no longer under active development and are no longer supported by active Collaborators. Only the TSC can decide to move a *Primary* platform to *Deprecated* status. Support for *Deprecated* Platforms may be removed entirely after the next *semver-major* version increase. +It is possible for build and CI infrastructure updates to cause failures in existing *Supported* platforms. This can happen, for instance, when an updated dependency forces the build to use an updated toolchain that is not yet (or no longer) supported on a given platform. In such cases, Collaborators should be notified in advance that such changes are expected so that appropriate fixes on affected platforms can be planned and landed. Effort should be made to ensure that the build and CI infrastructure continues to work on all currently *Supported* platforms. Prior to the next release, however, if it becomes clear that the build cannot be fixed on a particular platform, it can be moved to *Deprecated* status and landing the changes would require a *semver-major* version increase. + +Support for *Deprecated* Platforms may be removed entirely after the next *semver-major* version increase. + +Note that the option to deprecate an existing supported platform should not be taken lightly. Given that deprecation of the platform would require a *semver-major* version increase, such changes must be reviewed and approved by the TSC. ### Dependency Stability #### JavaScript Support (V8) -Node.js will adopt new V8 releases as quickly as practically feasible. For LTS Releases, the version of V8 shipped must be fully functional with no regressions on all *Primary* Platforms. +Node.js will adopt new V8 releases as quickly as practically feasible. For Releases, the version of V8 shipped must be fully functional with no regressions on all *Supported* platforms. When V8 ships a breaking change to their C++ API that can be handled by the binary abstraction layer there will be a *semver-minor* version increase. @@ -362,6 +301,16 @@ When dependencies introduce additional functionality that does not break backwar While the `npm` utility is shipped as part of Node.js, it is not a functional dependency in the same way as V8, OpenSSL or libuv. Specifically, `npm` is not considered part of the Node.js API. As a general rule, *semver-patch* and *semver-minor* updates in `npm` may be introduced into Node.js with only a *semver-patch* version increase. If there is a *semver-major* update in `npm`, such as when `npm` rolls over to version 3.0.0, then a *semver-major* version increase should occur in Node.js. However, the TSC may alter this policy in the future depending on the nature and scope of changes expected in newer versions of `npm`. +## Developer's Certificate of Origin 1.0 + +By making a contribution to this project, I certify that: + +(a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or + +(b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or + +(c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. + ## A Few Open Questions 1. What about things like http_parser and libuv? Does it make sense to see about bringing each into the foundation as their own projects? @@ -369,10 +318,8 @@ While the `npm` utility is shipped as part of Node.js, it is not a functional de ## Notes -1. The existing Node.js Workflow (https://nodejs.org/documentation/workflow/) contains the notion of "Milestones" (https://nodejs.org/documentation/workflow/#index_md_flexible_workflow_only_two_strict_rules). These are essentially Long Term Support Release targets used as goalposts for landing specific edits. The "LTS Candidate" process described in the Long Term Release section above would largely replace the Milestone mechanism. When the LTS WG declares that a particular Major.Minor release is an LTS Candidate, a Milestone should be created identifying it as such. The PR or Issue can then be associated so that Issues or PR's that should be landed or closed before cutting the LTS Release can be tracked. - -2. The existing Node.js Workflow requires that all PR's can only be landed using a specific Jenkin's "node-accept-pull-request" job. This document requires that all PR's must be tested to ensure that all tests pass but it does not go into specific detail on the CI process. It is expected that a Release Working Group will establish the specific step-by-step process by which Pull Requests must be landed. +1. The existing Node.js Workflow requires that all PR's can only be landed using a specific Jenkin's "node-accept-pull-request" job. This document requires that all PR's must be tested to ensure that all tests pass but it does not go into specific detail on the CI process. It is expected that the TSC will establish the specific step-by-step process by which Pull Requests must be landed. -3. The existing Node.js Workflow recently introduced the notion of "Priority" and "Status" tags for Issues. For instance, the *P-0* tag can be used to label issues that break node on at least one supported platform and need to be resolved as quickly as possible. The intent of the Priority tags is to assist in the triage of issues and help Collaborators determine which issues to work on first. The io.js project currently does not have a similar mechanism and feedback from io.js participants has been that such a Priority tagging system may not be of use (and could be actively harmful) given the way they've chosen to handle issues. +2. The existing Node.js Workflow recently introduced the notion of "Priority" and "Status" tags for Issues. For instance, the *P-0* tag can be used to label issues that break node on at least one supported platform and need to be resolved as quickly as possible. The intent of the Priority tags is to assist in the triage of issues and help Collaborators determine which issues to work on first. The io.js project currently does not have a similar mechanism and feedback from io.js participants has been that such a Priority tagging system may not be of use (and could be actively harmful) given the way they've chosen to handle issues. -4. Within io.js, the Binary Abstraction Layer of choice is currently `NAN`. Several of the Node.js contributors are not yet sure if `NAN` is the right choice. This will need to be decided at some point. For now, I've abstracted the abstraction layer in this document. +3. Within io.js, the Binary Abstraction Layer of choice is currently `NAN`. Several of the Node.js contributors are not yet sure if `NAN` is the right choice. This will need to be decided at some point. For now, I've abstracted the abstraction layer in this document.