This is a living document, it describes the policy and priorities as they exist today but can evolve over time.
The most important consideration in every code change is the impact it will have, positive or negative, on the ecosystem (modules and applications).
io.js does not remove stdlib JS API.
Shipping with current and well supported dependencies is the best way to ensure long term stability of the platform. When those dependencies are no longer maintained io.js will take on their continued maintenance as part of our Long Term Support policy.
io.js will continue to adopt new V8 releases.
nan
the minor version of io.js will be increased.nan
the major version of io.js will be increased.No new API will be added in patch releases.
Any API addition will cause an increase in the minor version.
io.js supports old versions for as long as community members are fixing bugs in them.
As long as there is a community back porting bug fixes we will push patch releases for those versions of io.js.
When old versions of dependencies like V8 are no longer supported by their project io.js will take on the responsibility of maintenance to ensure continued long term support in io.js patch releases.
Channels are points of collaboration with the broader community and are not strictly scoped to a repository or branch.
In order for io.js to stay competitive we need to work on the next generation of the platform which will more accurately integrate and reflect the advancements in the language and the ecosystem.
While this constitutes a great leap forward for the platform we will be making this leap without breaking backwards compatibility with the existing ecosystem of modules.
Debugging is one of the first things from everyone‘s mouth, both developer and enterprise, when describing trouble they’ve had with node.js/io.js.
The goal of io.js' effort is to build a healthy debugging and tracing ecosystem and not to try and build any “silver bullet” features for core (like the domains debacle).
The Tracing WG is driving this effort:
In order to maintain a good release cadence without harming compatibility we must do a better job of understanding exactly what impact a particular change or release will have on the ecosystem. This requires new automation.
The initial goals for this automation are relatively simple but will create a baseline toolchain we can continue to improve upon.