Repository navigation
Initial Release #28
Description
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
buildconfident we can have enough automation in place to hit this date. - Is the plan to have the installer install an
iojsbinary and an alias tonode?
Activity
SomeoneWeird commentedon Dec 2, 2014
Absolutely +1.
I think this should work, but it should check if node is already installed and not alias if it is.
creationix commentedon Dec 2, 2014
I have a concern and a question.
First to me it seems that weekly is too often. I understand you're trying to balance the insanely slow pace of recent node development, but don't flip to the other extreme. How much effort is it to cut a release? I know for me a luvi release takes a couple hours, iojs is a bit more involved, but also has a lot more supporting scripts.
Second, I love the idea of pulling in V8 changes as fast as possible. What ever happened to the idea to create a new C API layer that shields addon authors from V8 API changes? I could offer some help here but I thought Trevor has some ideas here and was farther along. Would this need to get in before a 1.0.0 release or could it just be a 1.1.x thing or 2.0.x thing?
domenic commentedon Dec 2, 2014
I am curious what differentiates 1.0.0-alpha.1 from 1.0.0? Perhaps that is your
I am leery of a long series of alpha/beta/gamma releases before a true, semver-ful 1.0.0 is released. All in all I would prefer a 1.0.0 release as the initial release---unless the TC anticipates actually making breaking changes in the subsequent releases.
indutny commentedon Dec 2, 2014
@creationix the idea with shielding C API was rejected. V8 should stay more stable in next versions, as they have finished their major API migration.
mikeal commentedon Dec 2, 2014
The goal is zero and that everything is entirely automated. Without that I don't think weekly releases are practical at all.
cjihrig commentedon Dec 2, 2014
Wasn't nan at least partially blessed in node-forward for shielding addon developers as well?
chrisdickinson commentedon Dec 2, 2014
Curious: what does this mean for changing core primitives, like streams, going forward? Are they effectively locked now?
Other questions / concerns:
mikeal commentedon Dec 2, 2014
@domenic I would be cautious about a brand new build, release and test system. I'd like to put out some alphas that people can use just to shake out any bugs and build confidence before we stamp something 1.0.
espadrine commentedon Dec 2, 2014
I wonder what the plan is regarding the adoption of ES6 features. Specifically, modules and promises. iojs currently has competing technologies, and it could potentially transition. Would that trigger a major version increment, and therefore, be the 2.0.0 version?
ghostbar commentedon Dec 2, 2014
@mikeal agreed, I think the -alpha makes sense for watching out for new bugs, even a -rc0,1,2,3...
therebelrobot commentedon Dec 2, 2014
@ghostbar @mikeal 👍
mikeal commentedon Dec 2, 2014
@chrisdickinson well... the last few changes to streams required full backward compatibility (or at least what we thought was fully compatible) because of the mountain of existing dependencies. I would expect additional changes to run through the same gamut, although with semver we do have a way to signal that a compatibility break is happening, but there is still going to be a big cost benefit analysis on breaking something so depended upon.
that said, you could see a future where moving toward or being more compatible with the upcoming streams work @domenic is doing as being the kind of benefit that might push a breaking change over the edge.
basicallydan commentedon Dec 2, 2014
I think an alias to
nodewould be useful but not by default. An uneducated user who doesn't know about the relationship between iojs and Node might not be expecting it.creationix commentedon Dec 2, 2014
Regarding the locked primitives. I highly recommending splitting the code into core and sugar like I did for luvit. The
luvmodule is just libuv bindings for lua. We could have just libuv bindings for v8. Then theluviproject is luajit + luv + openssl + other C libraries, but zero API sugar. Very C-like APIs. This would be the mythicalno.jsproject. Thenluvitis the full node.js style APIs with node streams, event emitters, etc all implemented in pure lua on top of luvi. That's the equivalent to node.js/iojs level of abstraction.I know this is harder for node because of how optimization was done mixing the lines between bindings and sugar, but I still think it's the only viable future to preserve the current APIs that everyone uses and enable a clean way to explore other styles while still reusing the C core of node.
mikeal commentedon Dec 2, 2014
This is going to end up depending on the level of adoption in each version and how many contributors we end up bring on board. It's not something we should commit to now except to say that "until we say we're deprecating support of a release all releases are supported."
We want nightly builds, and this weekly swap is probably also a good idea.
78 remaining items
guybrush commentedon Dec 9, 2014
looking forward to use my n-semver with semver'ed io.js :)
Nicolab commentedon Dec 13, 2014
io.js takes a good direction, exciting!
Solido commentedon Jan 8, 2015
I was in doubt with node.js but I started to learn ES6 just by confidence in IO.JS to be the next platform
siliconprime-tung commentedon Jan 14, 2015
will it be released today?
mathiasbynens commentedon Jan 14, 2015
@siliconprime-tung: It has been released already! Get io.js v1.0.1 here: https://iojs.org/
MoOx commentedon Jan 14, 2015
This issue should be closed.
chrisdickinson commentedon Jan 14, 2015
Congrats all! Closing this as fixed. ❤️
davidhuang3 commentedon Jan 14, 2015
Glad to see it.
Changes var to const/let in tls-ecdh; nodejs#28 from nina16
test: changes var to const/let in tls-ecdh; nodejs#28 from nina16
test: changes var to const/let in tls-ecdh; nodejs#28 from nina16
deps: V8: cherry-pick 482e5c7750b3
deps: V8: cherry-pick 482e5c7750b3