For Node.js core APIs, there is a deprecation strategy that requires at least one major version cycle before anything can be removed, and even then the chances of things actually being removed are slim. We're trying to take a very cautious and conservative approach to breaking changes in core. Generally, if it works in v4, it should continue to work in v5, if it doesn't, that's a bug that should be reported and fixed.Changes in npm, on the other hand are a different story. Technically, npm is not part of Node core, it's a utility that we bundle with the core but it has it's own lifecycle, it's own process and it's own separate project. The "contract" between npm and node.js is still being worked out and this kind of feedback is extremely useful.
BinaryIdiot|10 years ago
Considering there was 52 days between one major version cycle that criteria isn't really useful; I'd expect a timeframe more than a version cycle.
> Changes in npm, on the other hand are a different story. Technically, npm is not part of Node core, it's a utility that we bundle with the core but it has it's own lifecycle, it's own process and it's own separate project. The "contract" between npm and node.js is still being worked out and this kind of feedback is extremely useful.
I really should have said the main issue is really just writing code with node and sharing it; node has essentially been given the responsibility of being a standard set of libraries for JavaScript on the server and having standard libraries change APIs, even minor, in less than 2 months is typically indicative of a language pre 1.0.
But I'm hopeful you're right and things should continue working in most respects, it's just the edge cases that worry me. I don't want to spend a ton of time developing something that ends up simply not working in the very next version without a good path of providing my code that works with both.