Another point release, the future marches on, Node continues to fall behind. Everyone happily continues to not care what happens to it as the Node foundation... does whatever it is it's doing.
We don't all need to get up and clap every two weeks when they release a new version; this should just be life as normal really.
This is an interesting side effect of the 'release train' model. Releases used to be a big deal, but for many projects, they're not a big deal anymore. It's really nice from an engineering perspective, but it reduces your ability to market in the same way as before.
External curious observer (don't do anything Node-related) here. Hadn't heard of io.js before. Interesting.
Is this genuinely more popular than Node, or is this one of those cases where the HN crowd is skewed in its favour? Does it look like it'll take over as the standard server-side async JS system?
Also how close is it to being a drop-in replacement for Node?
tl;dr is that all the core contributors outside Joyent started working on io.js with an open governance model. Everyone wants to join back together but only after Joyent agrees to put node under the same governance model.
Instead of downvoting, could you please explain? All I see there is some node-but-not-so-joyenty stuff without much substance. What is the problem being solved?
You're looking at the Changelog. The README is next door, and it explains:
> This repository began as a GitHub fork of joyent/node.
> io.js contributions, releases, and contributorship are under an open governance model. We intend to land, with increasing regularity, releases which are compatible with the npm ecosystem that has been built to date for Node.js.
That doesn't tell me anything. It assumes the reader is somehow familiar with the context and shares the authors' sentiment, although that is not true.
This is what should be explained there:
1. What is the problem with Node.js?
2. What is wrong with Joyent?
3. Why the fork was the only adequate solution?
4. How come this is beneficial (and not harmful) to the community?
5. Is it a drop-in replacement? How does it affect existing projects?
6. How the future looks like from this point of view?
However hard I look at that paragraph in Readme, I still can't see these questions answered.
Sure, it's just a number, but the changelog isn't that big. Version inflation for no particular reason, apart from marketing, seems a bit silly. What am I missing?
This is a case of the Semantic Versioning doing the job it was designed for.
The 1.3.0 release just broke some poor regex I had written, since url.resolve now returns a trailing slash. Since it's a commonly used function, I have a feeling it might break a few apps out there. You shouldn't be making that kind of change in a PATCH number update. Hence the MINOR number update, perhaps.
That's semver doing the job people wish it were designed for, not semver doing the job it was designed for.
If it broke actual user code, then it MUST be a major version bump: "Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version, and backwards incompatible API changes increment the major version." The idea with semver is that you can ask for 1.2.0 or any greater 1.x.y, and your app will still work. This was broken.
Maybe there's an argument that the break didn't matter that much, but it's still a spec violation. Which is why you get a bunch of annoyed people who care deeply about ABI compatibility, when asked to switch to semver, saying, "Do you really want me to release version 172.0.0?" If the rule is, bump major versions when the project maintainers think it matters, bump minor versions when they think it matters less, bump patch versions when they're pretty sure it doesn't matter, that's exactly what gets derided as "Sentimental Versioning" (http://sentimentalversioning.org/), just dressed up as semver, which is more harmful.
If you've got to pay attention to every release's changelog and run regression tests anyway, just in case the package maintainers disagree about what's important enough for a major version bump, then you have version lock problems anyway. If semver is just guidelines and not a spec, then it should make that clear.
There's nothing in the semver spec that allows bumping just the minor version for a backwards-incompatible API change because a change was a bugfix. The rules are:
> increment the MAJOR version when you make incompatible API changes,
> MINOR version when you add functionality in a backwards-compatible manner, and
> PATCH version when you make backwards-compatible bug fixes.
Minor versions aren't for less-important API breaks. They're for new functionality. If it breaks API, it's a major version; if not, it's a patch.
It is to semver's credit that it doesn't allow the maintainer any discretion here; many communities (like the Linux kernel community) have learned through experience that determining whether something is "just" a bugfix is impossible. Google for 'don't break userspace' and you'll find Linus flaming people for changing which error code gets returned from certain operations. Semver's rule is backwards-compatibility, which is a bright line: if the bug was that an interface didn't work at all in some or all cases, or it returned unusable results, then that failure is not part of the API and it can be fixed. If it caused something to have worked differently, in ways that people could have written software to assume the "wrong" but workable behavior, then it's part of the API.
It is not to semver's credit that it doesn't define the terms "backwards-compatible" or "public API," but I think those terms have clear enough meanings in practice. In particular, anything documented and in use is part of the public API, even if the docs don't match the actual behavior.
If a project really wants to say "semver, but our docs define the API, not the implmentation", they can do that, assuming their docs are in fact thorough enough that you can write a correct program without having a copy of the implementation. But that's also getting really close to "semver, except when we don't feel like it"... which is probably what everyone does in practice.
If it's a change that breaks code using the API, shouldn't it be a major version - 2.0? If you update the minor version all your changes should be backwards compatible. If you can't run an existing program, that's not backwards compatible.
They are following semver which mandates that the MINOR should be incremented if the release contains functional changes. The only reason for incrementing PATCH is if the release only contains bugfixes.
This prompted me to look up Node's versioning style to see if it had a name, but I couldn't find one.
What I did learn is how in Node.js even numbered releases are stable and odd numbered releases are unstable. That seems pretty odd to me (no pun intended), is this normal?
I think religious following of semver doesn't matter, but
semver says that pre 1.0 numbers are essentially meaningless so nodejs might be actually following it correctly.
> Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.
> if your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you're worrying a lot about backwards compatibility, you should probably already be 1.0.0.
So, either they are using 0.y.z to allow themselves breaking changes whenever, or they are using it as a signal that it's not production-ready, or they are not following semantic versioning.
in 1.1.0 they added a couple new features such as privateEncrypt/publicDecrypt functions and publicEncrypt being able to accept a password protected private key (because you can derive a public key from a private key). These where new features so version bump.
1.2.0 added simplified stream construction so instead of being forced to subclass the built ins you could pass transform/flush/read/write/writev options to the constructor, again added feature so minor version.
1.3.0 changed the ordering of the default cipher suites so that more browsers would have perfect forward security by default. While not technically an api addition it's still more then a bug fix as it changes intended behavior so minor version.
I was mistaken that it was skipped. I haven't updated since 1.0.4 and missed it in the changelog (it is there).
In hindsight the version makes sense, but I was genuinely surprised by the version number and oblivious to semver, obviously. It feels like a big departure from the old node system. Not to say that's a bad thing.
The psychological effect of so many perceived changes on a platform may make it seem more unstable than it is. Having said that, io.js progress is great news for everyone in the JS/node/io community.
Doesn't seem like it, it's just the "RHEL" edition when compared to "Fedora" - slower, steadier release pace that focuses on stability, not features.
EDIT:
Downvotes ahoy.
Let's be honest here. Stable code (especially stable threaded code) requires QA time after adding new features. There are commits in this release which are less than 5 days old. 5 days is not enough time to shake out bugs.
Given that the developers are human, unit tests are incapable of finding all issues, and QA resources cost money, there is no way that this release could be considered to be stable.
A company would deploy this at their own risk, knowing that it's likely to have bugs which will have to be reported and fixed.
Not all companies can afford to take on that kind of risk, ergo a release like Node.js, which trails behind the bleeding edge of these technologies, makes sense to exist.
From what I understand, the "stability" argument, made by many for node.js, is a bit meaningless.
Node.js uses an old V8 version ( Google doesn't support it anymore, and they don't even apply security patches to it ) while io.js has the latest V8, plus all the security patches and bug fixes from the io.js codebase, that node.js does not have.
Same story with libuv, the "main" library under the hood.
Google offers support for v8 outside of Chrom(e|ium)? I can't find anywhere that Google lists what their supported versions of v8 are. Can you point me towards that list?
More importantly, has Google shown genuine interest in supporting embedding v8? Their last blog post about this was in 2012.
As for libuv, I would rather use a battle tested version, than stay on the bleeding edge. Threading is hard, and race conditions are rarely caught by tests. I'm happy to let others break their production and identify the regressions before I commit to it.
Wanting to use proven software has no relation to using the "oldest" version. As software is used, bugs are found. The longer you wait to transition to using new features, the fewer bugs you will encounter when you make the transition. What's nonsensical about that?
The V8 question seems to come up a lot, but the V8 team only supports any branch for 6 weeks after it becomes stable for Chrome.[1] If this is your definition of supported, then if you plan to use any version of Node or io.js for more than 6 weeks, you'll wind up on an unsupported branch.
Thinking that Node is somehow more "stable" means you've fallen for Joyent's marketing tendrils.
When Joyent or other enterprisey Node users mean "stable" they mean it in the same sense as Windows XP is "stable". It means you have a bunch of dependencies designed to work with a specific version, and you don't want to do the work of migrating because you have bigger cheques to cash. Stable doesn't mean less features, less bugs, or a slower release pace. Those things just fall out as consequences.
This is also the essence of why io.js happened in the first place. The intened audiences are completely different.
That's probably true... with developers starting to favor things like docker and micro services, along with CI/CD flows all the way to production, it comes down to being very easy to create, test and deploy your services against new libraries, or even replace them with better performing versions as needed.
To be fair io.js also focuses on stability and communicating the stability through proper use of semantic versioning. It's not like io.js wouldn't be production ready.
I don't have a report to link to, but experience certainly says so. I'll make another broad statement: I don't think most experienced engineers would argue with me that the more quickly changes are made to software (which implies a large volume of changes as well) introduces less stability over time. Or certainly greater risk.
I would also point out that the parent thread is good evidence. My point was that SemVer didn't save them from making a mistake, nor did the lack of SemVer save Underscore the other night. Volatility is what bit people.
When old software has bugs that don't get fixed, that also poses risk (see many recent high-profile security flaws). People just tend to overlook these problems more.
Simply waiting between commits reduces the rate of change, but does not increase the thoroughness of QA. In terms of defects, a project with very good, careful QA (any remotely acceptable strategy for reducing defects) will be at an advantage at every rate of change to a project which is just people pushing to master.
Some forms of careful QA impose a lot of latency between the decision to change and the change actually hitting, but that doesn't necessarily imply a reduction in throughput of changes per unit time, and it isn't the time which is reducing the defects but what is being done with that time.
I think that depends on your workflow as much as anything else. There are ways to mitigate the risks of moving fast, unit testing, integration tests, sanity checks, rolling deployments, service layers (micro services), etc...
By establishing the mindset that what you are pushing into master will make its way into production, you look at things very differently, with a much more critical eye. There are waterfall designed systems that took years to develop that made it to production with bugs... is a bug that breaks things for 5 minutes worse than one that sits for months, or a security fix that isn't deployed and might be exploited because your review process takes weeks?
If you mean which version, the changelog says version 2.5.1 in that release.
If you're asking if io.js is using a different npm, no it's using the same as Node.
You use io.js pretty much like "another version of node" which is why you'd use nvm if you want to have both io and node on the same system (same way you'd use nvm to have two versions of node on the same system) or just straight upgrade/replace, like replacing 0.10 by 0.12.
> The official name is io.js, which should never be capitalized, especially not at the start of a sentence, unless it is being displayed in a location that is customarily all-caps (such as the title of man pages).
The official name of Io.js in English is Io.js as it's a name, it is stylized as io.js. In Canada here, we have a company Telus, which stylizes it's name as TELUS. However, when discussing the company in non-marketing environments, such as Wikipedia, it's called Telus. The rules for English trump a creators stylization rules in many situations.
At least in my communications department, we follow a style guide — like Bloomberg's — and capitalize for our own purposes, rather than to further the marketing of another company.
E.g., "iPad, iPod, iTunes. Follow the company style for capitalization in text: iPad, iPod, iTunes. In headlines, capitalize because the words are nouns: IPad, IPod, ITunes."
Winkler, Matthew (2011-10-14). The Bloomberg Way: A Guide for Reporters and Editors (p. 304). Wiley. Kindle Edition.
And: "When a name begins with a lowercase letter, capitalize the first letter in all references: EBay, not eBay; EasyJet, not easyJet."
Winkler, Matthew (2011-10-14). The Bloomberg Way: A Guide for Reporters and Editors (p. 271). Wiley. Kindle Edition.
As far as I can tell, The Bloomberg Way is the only major guide that encourages that, and Bloomberg's own editorial standards are inconsistent such that they only use it half of the time: https://www.google.com/search?q=site:bloomberg.com+iphone
A quick search on www.bloomberg.com shows inconsistent application of the style guide. iPhone is universally styled as "iPhone", while both EBay/eBay and iTunes/ITunes appeared in headlines.
The Observer (to take just one newspaper) disagrees with StackExchange. To quote from their style guide:
"In general, where companies have resorted to unusual typography for undoubtedly innovative and exciting reasons of branding and marketing, we will follow our style,not theirs."
Of course, in your newspaper, you are free to make up your own rules. If you strongly believe in the tenets of "You shouldn't" then English is probably not the right language for you.
Ha, that's interesting. Yes, same Observer, but they've changed the style guide since I saved a copy. For reference, this is the full context I was referring to:
"Adidas: use initial cap on this and any other firms that use the lower case for their initial letter. Keep caps that break up a one-word name (cf EastEnders) as in EasyJet. In general, where companies have resorted to unusual typography for undoubtedly innovative and exciting reasons of branding and marketing, we will follow our style, not theirs."
When I was editing a consumer magazine, the - highly subjective - rule I followed was "initial cap unless it looks stupid, and don't capitalise articles". So EasyJet, C2C, but iPhone (fails "looks stupid" test) and the Times (definite article).
Stack exchange as a source of fact? I very much could be wrong, but the implication that "because 30 people upvoted something, makes it true" is ridiculous.
It's a power game showing who's the boss. Submitting to rules about spelling shows obedience. You can't work on Sundays and you must spell our products with a small i. Do not take the Lord's name in vain.
Bullshit. In a scientific setting, would you start your sentence as, "MRNA is the messenger RNA"? Somethings are purposefully stylized differently. mRNA, iPhone, io.js, etc. Naming conventions should be respected to aid clarity.
Science has multiple capitalization rules as well. mRNA is not a name, the same as genus and species are seldom capitalized. If you have a mRNA named Bob, then the name is capitalized.
No, the official name for io.js is io.js, it is explicitly not Io.js. You can tell because this is what the owners of the project have clearly stated. Linguistic rules (which are rarely in fact rules), have nothing to do with it. If I tell you my name is "bob" and not "Bob" then I'm right because it's my name, you don't get to enforce your own preferences, just because of the language you speak.
Some background: https://community.qualys.com/blogs/securitylabs/2013/03/19/r...