
Io.js 1.3.0 released - antouank
https://github.com/iojs/io.js/blob/v1.x/CHANGELOG.md#2015-02-20-version-130-rvagg
======
nailer
Good stuff: RC4 is officially removed from the (edit: default set of, thanks
ewegrump) cipher suites.

Some background:
[https://community.qualys.com/blogs/securitylabs/2013/03/19/r...](https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-
tls-is-broken-now-what)

~~~
ewegrump
It's not removed, it's just not in the default list anymore. You can re-enable
it with an option if you really do care.

~~~
silverwind
Correct, RC4 will still be supported until OpenSSL drops it, which is probably
never.

------
shadowmint
Nice, but to be fair, nothing much to see here.

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.

~~~
general_failure
Do you know any major player supporting iojs? Like aws, heroku.

~~~
neiled
heroku is: [https://devcenter.heroku.com/changelog-
items/595](https://devcenter.heroku.com/changelog-items/595)

------
miralabs
Isaac Schleuter and Mikeal Rogers was recently in Javascript Jabber talking
about io.js and mostly answers questions below. [http://devchat.tv/js-
jabber/147-jsj-io-js-with-isaac-schleut...](http://devchat.tv/js-
jabber/147-jsj-io-js-with-isaac-schleuter-and-mikeal-rogers)

------
bjackman
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?

~~~
silverwind
It's a 0.12 drop-in replacement with some minor API enhancements and a lot of
bug fixes.

Also, all current v8 ES6 features are enabled in io.js by default, while they
still require the --harmony flag on node.

~~~
tracker1
Not all of the features, just those marked as stable in v8.

------
mike_ivanov
I've read the Changelog, the Readme and the FAQ, and I still don't understand
what is it. Am I an idiot?

~~~
mike_ivanov
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?

~~~
seppo0010
Read the other comments:
[https://news.ycombinator.com/item?id=9081053](https://news.ycombinator.com/item?id=9081053)

~~~
mike_ivanov
Why that is not a part of the Readme/FAQ?

~~~
hibbelig
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.

~~~
mike_ivanov
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.

Edit: typo

~~~
bronson
You didn't try very hard, did you?

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.

~~~
bronson
Downvoter, please tell me where I'm wrong?

------
3princip
What is the reasoning behind the version jumps?

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?

~~~
jeswin
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.

EDIT: url.resolve not path.resolve.

~~~
geofft
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/](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.

~~~
tracker1
Though it broke behavior, technically the previous behavior was a bug... the
minor bump reflects that bugfix (that changes behavior).

~~~
geofft
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.

------
CmonDev
So the Node.js is dead now?

~~~
falcolas
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.

~~~
antouank
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.

( most of this explained in this podcast [http://devchat.tv/js-jabber/147-jsj-
io-js-with-isaac-schleut...](http://devchat.tv/js-jabber/147-jsj-io-js-with-
isaac-schleuter-and-mikeal-rogers) )

If older === more stable, then I guess you should use the oldest version in
everything. Makes no sense.

~~~
falcolas
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?

~~~
coderzach
Even "proven" software gets bug and security fixes. The version of v8 they're
using doesn't. Therefore, unsupported.

------
adamkochanowicz
So what is the NPM of io.js?

~~~
Fishrock123
npm stands for "no problem meatbag", not "node package manager" ;)

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.

------
scrapcode
> 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).

~~~
keslag
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.

~~~
integraton
That's not true at all. You shouldn't capitalize a brand name like iPhone, for
example.

[http://english.stackexchange.com/a/9065](http://english.stackexchange.com/a/9065)

~~~
seanstickle
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.

~~~
integraton
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](https://www.google.com/search?q=site:bloomberg.com+iphone)

