Io.js 1.3.0 released
github.com
github.com
Some background: https://community.qualys.com/blogs/securitylabs/2013/03/19/r...
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.
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?
See https://iojs.org/en/faq.html and https://iojs.org/en/es6.html
http://devchat.tv/js-jabber/147-jsj-io-js-with-isaac-schleut...
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.
Also, all current v8 ES6 features are enabled in io.js by default, while they still require the --harmony flag on node.
> 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.
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.
Edit: typo
1. answered by readme & faq (predictable release cycles)
2. answered by readme & faq (open source governance)
3. nonsensical question (who said io.js is the only adequate solution?)
4. loaded question
5a. mostly, look at the ES6 page or just try it out
5b. obviously no simple answer
6. subjective question. It looks bright to me.
1.0.3->1.0.4->1.2.0->1.3.0
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?
> 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.
Is there another alternative?
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?
http://perldoc.perl.org/perlfaq1.html#How-often-are-new-vers...
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.
EDIT: url.resolve not path.resolve.
From the discussion: "semver-major" label was removed because it is a bug fix: Node 0.10 has the new behavior, and also WHATWG compliance.
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.
> 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.
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.
All of the releases also a ton of bug fixes.
1.1 wasn't skipped:
$ nvm ls-remote | grep iojs-v1.1
iojs-v1.1.0In 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.
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.
Rather broad statement, that. Care to qualify it?
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.
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.
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?
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.
( most of this explained in this podcast http://devchat.tv/js-jabber/147-jsj-io-js-with-isaac-schleut... )
If older === more stable, then I guess you should use the oldest version in everything. Makes no sense.
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?
[1] https://groups.google.com/d/msg/v8-users/UUyavs0KtwE/dhh4F8c...
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.
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.
It's the package manager for javascript and will continue to be. The module system in io.js is not going to be changing anytime soon.
There's apparently immense social pressure to capitalize titles, but it isn't enforced by HN.
Bob went to the shop. When he got there, bob bought an icecream.
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.
"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.
https://www.google.com/search?q=site:theguardian.com+iphone
See the sections "capitals" and "company names" here http://www.theguardian.com/guardian-observer-style-guide-c
In particular:
"In general, we use the names that companies use themselves: c2c, Capgemini, easyJet, eBay, ebookers, iSoft Group, etc."
"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).