Initial Release about node HOT 97 CLOSED

We will be taking new v8 releases as fast as possible moving forward.

Absolutely +1.

Is the plan to have the installer install an iojs binary and an alias to node?

I think this should work, but it should check if node is already installed and not alias if it is.

from node.

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?

from node.

Will be 1.0-alpha1, with alpha releases continuing until 1.0.0.

I am curious what differentiates 1.0.0-alpha.1 from 1.0.0? Perhaps that is your

Are there any changes other than dep upgrades and fixes required for 1.0?

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.

from node.

@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.

from node.

How much effort is it to cut a release?

The goal is zero and that everything is entirely automated. Without that I don't think weekly releases are practical at all.

from node.

Wasn't nan at least partially blessed in node-forward for shielding addon developers as well?

from node.

If people disagree with any of those assumptions then they certainly won't agree with anything the TC determined for the initial release.

Curious: what does this mean for changing core primitives, like streams, going forward? Are they effectively locked now?

Other questions / concerns:

• How many prior major versions will be supported by core?
• How much lead time will the community have before a new major version drops? Is it possible to move towards a canary release system where one week's release is last week's canary, so we give folks who are instrumenting Node (cough cough @wraithan) enough time to adapt?

from node.

@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.

from node.

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?

from node.

@mikeal agreed, I think the -alpha makes sense for watching out for new bugs, even a -rc0,1,2,3...

from node.

@ghostbar @mikeal 👍

from node.

@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.

from node.

I think an alias to node would 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.

from node.

Regarding the locked primitives. I highly recommending splitting the code into core and sugar like I did for luvit. The luv module is just libuv bindings for lua. We could have just libuv bindings for v8. Then the luvi project is luajit + luv + openssl + other C libraries, but zero API sugar. Very C-like APIs. This would be the mythical no.js project. Then luvit is 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.

from node.

How many prior major versions will be supported by core?

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."

How much lead time will the community have before a new major version drops? Is it possible to move towards a canary release system where one week's release is last week's canary, so we give folks who are instrumenting Node (cough cough @wraithan) enough time to adapt?

We want nightly builds, and this weekly swap is probably also a good idea.

from node.

Switching to semver.

👏

Is the plan to have the installer install an iojs binary and an alias to node?

I'm with @SomeoneWeird, it should not make the alias if node is already installed.

from node.

@cjihrig it is, gosh! I always forget about it :) please do not take it as offense.

from node.

Looks like a solid plan. One question, will v1 be based on node 0.10.x or 0.11.x?

from node.

@sintaxi the 0.12 branch here.

from node.

@mikeal sounds good. thanks.

from node.

@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.

That makes sense. Would just like to suggest making some sort of explicit commitment that the goal is to get a 1.0.0 out within a few releases or some time period. Maybe revisit the details of the commitment when 1.0.0-alpha.1 lands so you can take stock of what people think of the release.

All I'm saying is that as-is, the only stated goal is 1.0.0-alpha.1, with no thought toward a real 1.0.0, which makes me nervous that we'll end up like Ember and play around in the alpha/beta stage for half a year (similar to 0.12 being stuck in the 0.11 stage for ... well, forever).

from node.

@domenic all good points, I guess we should probably state that "no features will be added between 1.0-a1 and 1.0"

from node.

How about:

The goal of not immediately releasing v1.0.0 is to provide a buffer between v1.0.0-alpha1 and v1.0.0 to allow the build process to mature.

from node.

👍

from node.

@kenperkins perfect :)

from node.

I think this should work, but it should check if node is already installed and not alias if it is.

The problem with this is that the installer also installs npm which is going to link to a different node than the one accessible by node if already installed. Apparently, package managers have a way to mark a package as "conflicting" with another. We can use this to ensure proper warnings when installing iojs where nodejs may have already been installed.

from node.

Apparently, package managers have a way to mark a package as "conflicting" with another.

For sure, I guess it just makes testing/migrating to the other one slightly trickier.

from node.

👍 👏

from node.

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?

@espadrine also very curious about that, that is ES6's general role in io.js. Given ES6 brings quite a large number of changes there will be a large amount of questions coming up.

Any ideas how & where to manage ES6 related issues? A meta issue, a label? If there already is documentation I apologise and humbly ask for a link.

from node.

@SomeoneWeird well, let's be clear and honest about all this. iojs is an alternative/replacement for the node binary distributed by Joyent. In this, I would expect test/migrating between the two to be similar in difficulty as testing/migrating to any new version of node.

from node.

@ehd and @espadrine one thing at a time, how about we release a stable version where generators don't require a rebuild :) But seriously, just taking new versions of v8 with some regularity will be miles ahead of where we are today.

from node.

@mikeal Fair point, agreed.

from node.

ES6

I think the responsible thing to do here is to take ES6 features as fast as v8 is adding them and then observe what effect that has in the ecosystem before making alterations to core. Seeing how the features are used should be a central part of deciding how they might be adopted in core and until we are taking new v8 releases regularly we can't really do that.

from node.

@mikeal That sounds like a great plan. I'll get behind anything that empowers experimentation in the ecosystem and it looks like io.js will do a great job of that :)

from node.

I think the responsible thing to do here is to take ES6 features as fast as v8 is adding them and then observe what effect that has in the ecosystem before making alterations to core.

I agree with this in general. For example everyone likes to talk about modules (which of course aren't in V8 yet and there aren't any commits showing progress in that direction, but that's another story). I think the fair thing to do is let the community build integration tooling, module loader, etc. and see what people like, before rolling the best solution into core.

FWIW the only features of ES6 that I think could potentially impact io.js core at all are modules and promises. Everything else (classes, arrow functions, etc.) really only impacts user code. Maybe proxies and weak maps would let us move some stuff out of C++ into JS.

from node.

@domenic I think Promises don't need to affect core at all. They can remain in user code. Modules are the only conflicting feature. ES6 has 0 conflicts with ES5. Node.js only added CommonJS, and nothing else.

from node.

This is really exciting! Thanks for pulling the trigger on this.

What's the official message in terms of eco system fragmentation?

from node.

@alexgorbatchev there is no ecosystem fragmentation, there are 100K+ modules in npm that will work on iojs just like they work on nodejs. the only thing that is fracturing is the effort being put in to core, but if you take a look at the contribution graph for joyent/node there's nowhere to go but up :)

from node.

Very much looking forward to seeing where all this goes. 👍

from node.

Is the plan to have the installer install an iojs binary and an alias to node?

Could it also create an io alias as long as it doesn't conflict with Io? Much nicer to type.

from node.

I'd rather nobody try to put a binary at the name io. It's bad enough that ImageMagick takes names like convert (because, you know, nobody's ever going to convert anything that isn't an image).

In other news, what is this? Was this being discussed on the Node mailing list / Google group or something? I just heard about it now via someone submitting a link to this issue on Hacker News.

This would be some kind of project that automatically rebuilds the core Node components for every V8 release? Is it going to be developing the core modules itself without pushing back upstream? What about the modules that don't touch or have anything to do with V8 like url?

from node.

@creationix #9

If you are interested in the libuv.js approach we can poke more at it.

from node.

@creationix, @rvagg and the rest discussed a wrapper library for V8, as you are asking about, in one of the TC meeting videos (I apologize for not having the link), in the context of making an API abstraction across multiple js engines. I'm paraphrasing here, but as I understand, he said his experience from nan, specifically of working with user's of nan to get their addons working, was that the range and variety of V8 usage was so wide and varied, he didn't see creating a V8 subset API as useful (which is what a wrapper would necessarily be), since the addons he was seeing would still be reaching past it into unportable V8 direct usage. Having coded for years against lua's C API, I'm somewhat aghast at the, shall we say, "breadth" of the V8 API, but there doesn't seem to be a concrete plan to wrap that, other than to make sure every iojs core release is coupled (if necessary) with a nan release that covers that new release (and it's V8), with nan major number incrementing as necessary, when V8 changes sufficiently that nan can't cover it over with its current abstractions.

I hope I didn't misrepresent anything there, but that's the impression I have from watching the TC meeting.

from node.

Finally!

Semver + fast release cycles will be awesome.

How will it work regarding deciding what features to add? Will there be discussions on issues/prs so that everybody can give their opinion or will there be a board? What's th idea going forward? I saw about the Open Governance but just globally I mean.

The other question is once there're features that are different in io.js vs node.js. What will you do with packages fragmentation at that point? Any thoughts?

Thanks!

from node.

As someone who needs to instrument node/iojs, a weekly release cycle is scary to me unless we are doing a train type system akin to Firefox/Chrome where there is lag time between leveling up the release. Alpha out for x days/weeks, Beta for x days/weeks then finally a GA. This gives those of us who need to keep up with changes a real chance to do so.

This allows for other folks to run automated tests against these alphas/betas, and folks to actually try out the release before it goes live. Nightlies aren't enough when you are talking a weekly cycle since a change could go in on tuesday, and release on thursday for instance. Folks like me would have wednesday to notice that something broke, fix it, and then release it so we are ahead of the game.

This needs to apply to everything excepting perhaps security fixes. Patch versions that are just bug fixes can slightly change behavior in ways that will affect projects that instrument node. We are extremely defensive, as we have to be, but there are many possibilities for us to run into weird issues due to reliance on edge cases.

My proposal would be at least 1 week, preferably 2 weeks, from Alpha to Release of every release. Having a full week allows us to react and push a regular release instead of having to react with hotfixes all the time.

I anticipate being told that we should just track the repo more carefully ourselves. But if iojs takes off like node did, we are talking at least 1-3 new PRs every day for us to track, plus all old PRs that are actively being worked on. I consider that load to be unreasonable, even if we were to have a full time core dev on our team as they would spend 100% of their time evaluating new commits on PRs for threat to the agent. These numbers don't even consider libuv or v8, just the core repo.

from node.

Apparently, package managers have a way to mark a package as "conflicting" with another.

This would prevent people from having both installed on the same system, I could see someone wanting to do this. CI would be an example of this... I would want to test any modules I build against both nodejs and iojs to ensure compatibility.

An alternate approach would be to have a compatibility package. Have the base iojs package and an iojs-compat that simply aliases nodejs to iojs and let that package conflict with nodejs. That gives you the flexibility of an easy migration path for users while also making it possible to have the two packages co-exist on a machine.

from node.

@ptinsley what is the exact workflow of that feature? Does it literally uninstall the previous package before installing the new one that conflicts?

from node.

I'm all in favor of consistent, frequent releases, but a 1-week cycle seems a little too aggressive. With Chrome's 6-week cycle, four channels ("stable", "beta", "dev" and "canary") gives you 18 weeks to vet new code before it's released. 18 weeks might be too long, but with a 1-week cycle, you'd either need a lot more channels, or you'd have a lot less time to vet new code.

from node.

A new release does not mean you have to upgrade. Everyone has different risk profiles and having releases lets those with a higher risk tolerance to test them out quicker.

from node.

@mikeal @ptinsley for rpm specfiles conficts will cause rpm install to error out and state the conflicting package. This only happens if the conflicting package has also been installed as an rpm, and it can be over-ridden with --nodeps. I definitely agree that users need to be able to evaluate and transition gradually with both binaries installed for comparison. My preference would be to use a name that's not already taken (ie. iojs) and let users to set an alias or use a tool like nvm or n to manage it. Those tools already change the node symlink to point to one of several binaries on your system. I'm assuming nvm, n et al will be updated to support pulling from the iojs repo.

from node.

@mikeal On deb based systems, yes, that's how it works. (cant talk for the others)

@defunctzombie I'm not sure that helps @wraithan at all, because people will upgrade.

from node.

Re: making sure all 100k npm modules work on io.js, that's a bit of a dangerous promise. As the code base diverges, I doubt that will be the case. I doubt that's even true right now: last I checked, fibers only works on NodeJS 0.11.10, not 0.11.9 or 0.11.11 or 0.11.12. I haven't quite tested it with io.js yet, but just figured I'd voice my concern.

from node.

With n it looks like you can just export N_MIRROR=http://iojs.org/dist to start pulling from the new repo when it goes online. But I guess n still needs to be updated to look for either node / iojs as the target of the symlink.

from node.

We can work out how to stage this in a responsible way, the goal though should be: nightly builds, weekly usable releases (the stability standing of which we can figure out later).

from node.

@mikeal By saying it that way, you are closing off discussion. Is there a better place if you don't want us to discuss that sort of release detail here? That detail is VERY important when you start a thread declaring weekly releases, at least to folks like myself.

from node.

@wraithan I think @mikeal is being very fair here. We may all feel that a weekly release cycle is impossible, but we would need to first give them a chance. There are more details to be worked out.

iojs needs support and confidence to get off the ground.

from node.

@wraithan there is definitely going to be a discussion about that but I think it should start once we have at lease one release up :) I think that weekly cycles for alpha releases to get to 1.0 is a pretty good idea, after that we take take what we've learned and roll it in to a better plan. I don't mean to end discussion, I just don't think we can have a very informed discussion until we have releases and a build process that enables us to get stuff out fast.

from node.

We deploy in scenarios where upgrades usually mean putting someone on a plane. So I'm all for rapid releases but I think there should also be something like an LTS build that contains all the fixes but takes a conservative approach to including new / unstable features.

from node.

@darrenderidder perhaps this is something automation can also help with. /cc @rvagg

from node.

LTS is definitely something that's been discussed by the TC (previously in node-forward form) and something that a lot of us want. Even if it ends up being too difficult for the TC here, we at NodeSource would certainly be interested in investing in helping maintain a regular series of LTS releases--a significant portion of our customers are on the RHEL release cycle where they are used to getting platform support for (literally) decades. Many of them are only now just making the transition from RHEL5 to RHEL6, which is still ancient. So they want stability and assurance and we're up for that.
Either way, it's on my personal agenda and NodeSource's agenda so we'll make sure there is some form of LTS in the long run.

As @mikeal said in response to @wraithan:

I think it should start once we have at lease one release up

So let's not get too ahead of ourselves, we need to ship something and then refine the process from there, for all we know, semver + regular releases + V8-crazy for a user-facing project like this may be a total failure and we need to adapt.

The title of this issue is Initial Release, let's aim for that!

from node.

@rvagg sounds good
@mikeal automation is great and we run our own repos for rpms of some components but unfortunately automation isn't feasible for most of It. We're in some mission critical places where networks are heavily isolated, and similar to what Rod says about customers requiring long term support on sw configurations that are locked down for a long period of time.

from node.

Maybe it's a common question, but - a part of tech stuff, what happens to the production and/or enterprise node based ecosystem if we choose to move to io.js?
The project seems challenging, but will the modules developers move to io.js all together?
Supposed that it's fully compatible with node in the next future - and that's great, what's the opinion of mainstream node modules developers? Every one is happy about this?
I'm not talking about Ryan Dahl & co, but to node modules developers that is the real core of node.
If they do not support this fork, what happens?
Thanks.

from node.

What about 1.0 for alpha and 1.0.1 for final release? imo this is less confusing.

from node.

@loretoparisi I think it's easy to answer your concern if Node proper development stays stagnant; However, if for some reason there is a change in activity on Node that could create some significant contention, and/or a battle for developers/contributors.

from node.

@loretoparisi I think this will be comparable to the kind of adoption we see of any major release of Node, people migrate their servers and development environments to it as time allows or right away if they are excited about something present in the new release.

from node.

Nice guys! Are streams changing?

from node.

Ah, I think I misunderstood the weekly release cycle to mean that new versions were coming every week (1.0.0, 1.0.1, 1.0.2, ...). It sounds like you just meant that you would cut a new build every week. 👍

from node.

LTS is definitely something that's been discussed by the TC (previously in node-forward form) and something that a lot of us want. Even if it ends up being too difficult for the TC here, we at NodeSource would certainly be interested in investing in helping maintain a regular series of LTS releases--a significant portion of our customers are on the RHEL release cycle where they are used to getting platform support for (literally) decades.

FWIW, so would StrongLoop (and me personally) for pretty much the same reasons.

Details TBD: release schedules, how long to support each LTS release, how to manage dependencies (npm, v8, libuv, openssl), etc.

If other companies are interested in LTS releases and can commit resources to it (be they human or otherwise), now would be a good time to speak up. :-)

from node.

I think that's great to have a fork of Node.js, that would bring more support, stability and bugs catching and fixing. But What about the npm modules, how can they support both node.js and io.js especially when they diverge. Could io.js lose support of npm modules ?

from node.

There could be some breakage, but I think project aims to be compatible while moving forward.
I think compatibility with "essential" (express, socket.io, etc) modules is(should be?) one of the goals

from node.

Backward compatibility has always been a must. This is no different than other node major releases. Locked modules don't change, stable ones keep stable interfaces. Experimental ones might change, but that's been seldom. Some are more arguably broken like domains, so change is more likely.

The ABI changes with V8, but their assurances are that that is settling down, and their API is getting more stable. Binary linked modules are still shifting sands, but developers who want a stable api or abi are encouraged to participate and to experiment with projects like nan.

This is a fork of node but also sharing developers. Lots of opportunities to stay compatible. Test and give feedback, listen for proposed breaking or big changes. Pay attention to how stable the interface is for a module when you use it.

from node.

What about compatibility with node? io.js must have the same API as node? Or they will eventually diverge?

from node.

Can't predict the future, but nobody's going to break things on purpose. For now, compatible. If someone starts making hard-to-stay-compatible-with decisions that have problems, then we'll start seeing divergence.

from node.

I mean issues like #9, #11, and #5. These are huge breaking changes.

from node.

@madbence only #5 is a breaking change of those you list.

from node.

@domenic my bad, you're right about #11. Maybe I misunderstand #9, but for me it means that I have to list eg. http as a dependency (if it's not part of the core), so every npm module that uses http will break. Fix me if I'm wrong :-)

from node.

@madbence I mean it's a pretty vague idea but I'd imagine that core comes bundled with some modules that you can override local versions of in your project using npm.

from node.

I thought #9 is about developing projects separately (like libuv and node) ...

from node.

Yeah, #9 is about making the core be multiple separate projects that get packaged up at the build step and that is what is distributed. It may or may not be a breaking change.

from node.

WRT ES6 and Promises, I would certainly like to see a future where promisify-type methods aren't required. I've filed #88 for this. But that wouldn't be a backwards-incompability, except maybe for some existing functions which both take a callback and return a value. I don't know any of those off the top of my head.

WRT "changes other than dep upgrades and fixes required for 1.0" -- I think you shouldn't get hung up on the number. If there are incompatible changes that "should be made", just do them after 1.0 and increment the appropriate part of the version number as per semver. Lots of people use current node, it's plenty good enough to label as 1.0.

(My candidate for future possibly-incompatible change would be some reconciliation between node modules and ES6 modules -- but that's far in the future, no sense holding up 1.0 for it.)

from node.

w/r/t a symlink/alias for the node executable:

I think an alias to node would 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.

Frequently in the scripts section of npm's package.json, a module will have this:

"scripts": {
  "install": "node scripts/install.js"
}

Why? Windows doesn't know what to do with a shebang:

#!/usr/bin/env node

...so the install script cannot be simply be an executable scripts/install.js.

If someone is using iojs, and no node executable is present, the package will fail to install.

If I understand how running scripts with npm works, a potential hack around this would be for the npm packaged with iojs to attempt to put a symlink to the iojs executable at ./node_modules/.bin/node. (Assuming you can do that sort of thing with Windows; I'm a bit out of practice.)

(Edited to reflect proposed name of executable in /node-forward#19)

from node.

Out of curiosity, will io.js pull commits from node.js that make sense to apply, preserving some common git history beyond today?

from node.

@jamonholmgren we already have pulled a couple in :)

from node.

This is awesome!

What do you think about the idea of adding iojs to n and nvm?

Easy to switch between versions for developers + should then work in all CI servers who support n/nvm.

from node.

Adding to nvm would be such a great thing, easy install = easy testing = easy adoption.

from node.

@JamesKyburz @naholyr that is currently being discussed in #40

from node.

@cjihrig ok thx!

from node.

FWIW, nvm doesn't deal with symlinks at all. It works by putting a certain
version of node's bin folder front in the user's path in their current
shell session. Thus a user is able to have multiple shell sessions going
on at once with different versions of node in each one. And it can do this
without a subshell. n and nave use two other techniques and have their
own strengths and weaknesses.

But this means that if you want node in your path to run a certain
version of iojs, there needs to be a node binary in the iojs bin folder
or putting it first in the PATH won't mean anything.

On Sat, Dec 6, 2014 at 2:08 PM, James Kyburz [email protected]
wrote:

@cjihrig https://github.com/cjihrig ok thx!

—
Reply to this email directly or view it on GitHub
#28 (comment).

from node.

I think aliasing iojs to node should be used. It's generally a good practice, have a look at mysql/mariadb. You just install maria and you're ready to go.
Another option is to use iojs as a sub-version of node, which would still allow seamless switching.

from node.

looking forward to use my n-semver with semver'ed io.js :)

from node.

io.js takes a good direction, exciting!

from node.

I was in doubt with node.js but I started to learn ES6 just by confidence in IO.JS to be the next platform

from node.

will it be released today?

from node.

@siliconprime-tung: It has been released already! Get io.js v1.0.1 here: https://iojs.org/

from node.

This issue should be closed.

from node.

Congrats all! Closing this as fixed. ❤️

from node.

Glad to see it.

from node.