But why?
IO.js, a Node fork
11–20 of 30 posts
Re: IO.js, a Node fork
#12Re: IO.js, a Node fork
#13Re: IO.js, a Node fork
#14Re: IO.js, a Node fork
#15 * Indutny (listed as a Node.js code team member)
* Trevor Norris (also a Node.js core team member)
* Isaac Schlueter (cited as a Node.js core team alumni)
* Ben Noordhuis (also an alumni)
* Bert Belder (another alumni and a Node.js maintainer)
Compared to the Node list of top contributors:https://github.com/joyent/node/graphs/contributors
Here's some better information:
http://www.infoworld.com/article/2855057/application-develop...
Re: IO.js, a Node fork
#16Re: IO.js, a Node fork
#17Previous:
https://news.ycombinator.com/item?id=8694953 (Link to the repo)
https://news.ycombinator.com/item?id=8669557 (Another link to the repo)
At this point I'm just getting frustrated because I should be able to learn about important open-source issues from the community, not from a Wired article and not hidden in some secretive organization and private repo. Airing frustrations through Wired is only bad for the community -- the headline is nothing but FUD:
"Future of Popular Coding Tool In Doubt After Public Split" -- Can you imagine selling your CEO on Node when articles like this are being written?? Someone on HN posted this [1] recently, and I think it's very appropriate -- I believe this confusion could have been avoided:
> If, after careful consideration, you still conclude that you must fork, line up support privately first, then announce the fork in a non-hostile tone. Even if you are angry at, or disappointed with, the current maintainers, don't say that in the message. Just dispassionately state what led you to the decision to fork, and that you mean no ill will toward the project from which you're forking. Assuming that you do consider it a fork (as opposed to an emergency preservation of the original project), emphasize that you're forking the code and not the name, and choose a name that does not conflict with the project's name. You can use a name that contains or refers to the original name, as long as it does not open the door to identity confusion. Of course it's fine to explain prominently on the fork's home page that it descends from the original program, and even that it hopes to supplant it. Just don't make users' lives harder by forcing them to untangle an identity dispute.
Re: IO.js, a Node fork
#18Just a few I saw in the handful of issues I looked at: isaacs, mikeal, domenic, rvag
Re: IO.js, a Node fork
#19This is a big deal, because of who is involved. Here's the list of people involved: * Indutny (listed as a Node.js code team member) * Trevor Norris (also a Node.js core team member) * Isaac Schlueter (cited as a Node.js core team alumni) * Ben Noordhuis (also an alumni) * Bert Belder (another alumni and a Node.js maintainer) Compared to the Node list of top contributors: https://github.com/joyent/node/graphs/contrib…
Re: IO.js, a Node fork
#20 In the TC meeting today we came up with a vision for the first release.
First, a few assumptions we've internalized that probably need to be stated for this to make sense.
- Node is pretty damn stable already. There are huge companies with it in production, 100K+ modules, etc. It is already far more stable that its pre-1.0 release tag suggests.
- Releasing more frequently leads to a more stable product, not a less stable product.
- The entire ecosystem uses semver while node uses a confusing even/odd release structure.
If people disagree with any of those assumptions then they certainly won't agree with anything the TC determined for the initial release.
So, first release of io.js:
- January 13th (Fedor's Birthday!) target date.
- Will be 1.0-alpha1, with alpha releases continuing until 1.0.0.
- Switching to semver.
- We will be taking new v8 releases as fast as possible moving forward.
- Trying to get to a weekly release cycle. Which version number is incremented each week is determined by the changes and whether or not they are breaking. Again, following semver.
Some questions still left open:
- Are there any changes other than dep upgrades and fixes required for 1.0?
- Is build confident we can have enough automation in place to hit this date.
- Is the plan to have the installer install an iojs binary and an alias to node?
Source: https://github.com/iojs/io.js/issues/28