Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release proposal: v3.0.0 #1807

Closed
rvagg opened this issue May 27, 2015 · 95 comments
Closed

Release proposal: v3.0.0 #1807

rvagg opened this issue May 27, 2015 · 95 comments
Labels
meta Issues and PRs related to the general management of the project.

Comments

@rvagg
Copy link
Member

rvagg commented May 27, 2015

Currently this is a tracking PR for a 3.0.0 release, some discussion continues on from #1805. This proposal doesn't have a timeframe yet, there are too many unknowns at this stage but we may be able to proceed fairly quickly if things come together nicely.

To be honest I'm not sure exactly what the semver-major here is except for the V8 upgrade and I don't know the details about what's breaking in the C++ API there, perhaps @kkoopa, @bnoordhuis or @trevnorris could fill us in on the details of the breakage for the CHANGELOG? Is this the one where we get all the Maybe* API drama that's going to hurt for everyone?

V8 on the next branch is currently at 4.3.61.21, the CHANGELOG for that is at https://chromium.googlesource.com/v8/v8/+/4.3.61/ChangeLog

The only things on the JS side from scanning the changelog that may be relevant are:

  • Remove --harmony-scoping flag.
  • Implement subclassing Arrays (issue 3930).
  • [es6] Fix for-const loops (issue 3983).

@domenic could I put it on your TODO list to give us a summary of what's changed on the JavaScript end, if anything?

One outstanding item of concern is that I got multiple failures of test-debug-port-from-cmdline.js on OSX, caused by a hanging background process listening on the debug port--I don't know if it was this test on a previous run that caused that hanging process or not, however. If this keeps on showing up then it'll have to hold up a release until we find a fix.

Current log of commits is as follows, but I expect us to get a v2.1.1 out so this will change.

@rvagg
Copy link
Member Author

rvagg commented May 27, 2015

First release candidate for testing: https://iojs.org/download/next-nightly/v2.1.1-next-nightly2015052770716fdd93/ v3.0.0-RC1 perhaps?

@mscdex mscdex added the meta Issues and PRs related to the general management of the project. label May 27, 2015
@jbergstroem
Copy link
Member

Next seems to fail consistently on an arm7: https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/nodes=armv7-wheezy/714/tapTestReport/test.tap-180/ -- might be a pr/issue for it somewhere. If that's the case, sorry for not searching properly.

@rvagg
Copy link
Member Author

rvagg commented May 27, 2015

not consistent, but probably about as consistent as the OSX one, see https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/713/ for a successful one for example

@trevnorris
Copy link
Contributor

@rvagg I'm working on finishing the Uint8Array implementation of Buffer behind a flag. Though there are questions I have for the TC meeting tomorrow before it can be finished. This is something I would like to be released on v3.0, if possible.

If it is, I'll give you a full list of any API changes that come with it. Though it will be behind a flag, so one one should immediately feel it.

@kkoopa
Copy link

kkoopa commented May 27, 2015

Is this the one where we get all the Maybe* API drama that's going to hurt for everyone?

Yes, every single native addon ever written will need extensive rewriting and it cannot really be automated in a sensible way. Every npm package depending on a native addon will also need updating to pull in the new versions from their upstreams. In total, 64 000 packages may need updating.

This is way worse than those crummy Isolates.

@rvagg
Copy link
Member Author

rvagg commented May 27, 2015

@kkoopa what's the status of NAN for this? Is it having to wait for 2.0 to make this work? Got an ETA on that (sorry, I've been following but a little detached atm)

@kkoopa
Copy link

kkoopa commented May 27, 2015

Definitely 2.0, there is not a snowball's chance in hell of NAN 1.x working on io.js 3.0. nan/next builds against iojs/next. What is missing is mostly documentation and a conversion script. The sooner someone writes this, the sooner it can be released.

@imyller
Copy link
Member

imyller commented May 27, 2015

My humble suggestion:

Maybe it is time to consider adding and maintaining a Foreign Function Interface (FFI) in the core? Something like the node-ffi provides. Not as a replacement for current addon system, but as a less volatile alternative.

That wouldn't help the immediate package breakage 3.x.x brings, but would steer addon developers who do not need the full V8 native access to implement their own bindings in pure JS in the future.

@kkoopa
Copy link

kkoopa commented May 27, 2015

There already is.

@imyller
Copy link
Member

imyller commented May 27, 2015

@kkoopa Thanks, missed the FFI PR. Hope it goes through. Soon.

@kkoopa
Copy link

kkoopa commented May 27, 2015

Simply adding FFI still won't solve anything for many years to come, as people want their addons running on many versions of Node.

@imyller
Copy link
Member

imyller commented May 27, 2015

I just hope this doesn't turn in to Python 2 vs 3 for Node if the breakage too widespread. 64,000 packages @kkoopa mentioned is a huge chunk of the ecosystem.

@kkoopa
Copy link

kkoopa commented May 27, 2015

The problem with Python 2 vs Python 3 was that they kept on supporting Python 2 and even adding new features to it. They should have cut it off completely and let it die quickly and Python 2 would have died off within a year. Python 2 is strictly inferior to Python 3 and it is a shame that it is still in use.

@imyller
Copy link
Member

imyller commented May 27, 2015

Agreed. My 👍 goes for the incredible and fast progress io.js makes. An outstanding team behind it.

At the same time I'm also bit worried about the quickly progressing fragmentation of packages only supporting 1.x.x, then 2.x.x and soon 3.x.x. Some packages catch up, but at every step the ecosystem looses some permanently.

If important enough people outside the core start making choices like "oh, we are going to stick with 2.x.x because 3.x.x migration has been marginal" then it spells Python-like trouble for Node.

@kkoopa
Copy link

kkoopa commented May 27, 2015

In that case they will eventually get forked and updated by someone else with enough desire to support the future. Unlike the Python transition, by using NAN this will still be backwards compatible once updated, so the only reason for not updating is lack of motivation.

Also, while I don't have any figures, I'd imagine that the number of people using io.js 3 will be significantly less than those using any previous release since Node 0.8. For them, there is no imminent need to update every package under the sun the instant a new version is released. It will eventually happen in a gradual fashion as pressure builds up from io.js 3 users.

Also, io.js 2 was a bit of an anomaly in the sense that it was already known that all of this breakage would happen with the release of 3.0 a couple of weeks later, but that's what you get if you insist on releasing a new (major) version every time a dependency is updated every six weeks. There will be more breaking changes in another six weeks when io.js 4.0 is released with V8 4.4. I've tried to make sure all of this is accounted for already with the release of io.js 3.0 and NAN 2.0, to prevent such avoidable breakage, but unless packages take this into account when updating for io.js 3.0, some of them will have more fixing to do for 4.0.

If this release-a-new-major-every-six-weeks-thing is going to continue, it would be advisable to document what is known to break in future updates.

@Fishrock123
Copy link
Member

At the same time I'm also bit worried about the quickly progressing fragmentation of packages only supporting 1.x.x, then 2.x.x and soon 3.x.x. Some packages catch up, but at every step the ecosystem looses some permanently.

It may be worthwhile looking at our plans for LTS: https://github.com/nodejs/LTS/issues

Most modules should probably turn to future LTS for what versions(s) they support, except for modules that want to stay ontop of master. It's likely that the 2.x io.js line won't have one and will be recommended not to have one.

@Fishrock123
Copy link
Member

FWIW I also think it is quite important to get the new Buffer impl (flagged or not) into 3.0.0

@mikeal
Copy link
Contributor

mikeal commented May 27, 2015

Where does that 64K packages metric come from? Is that the deep dependency analysis of all nan dependents? nan has less than 500 direct dependents so only that many people would potentially need to change their own code, the rest of those 64K packages (assuming this metric is correct) will only need to update the versions of their deps and deps of deps and so on.

@domenic
Copy link
Contributor

domenic commented May 27, 2015

Why hold up on Buffer? Especially since it's flagged, we should be fine introducing in 3.1. Seems like a pretty clear "don't hold the train" scenario.

@mikeal
Copy link
Contributor

mikeal commented May 27, 2015

Just putting this out there, is there a compelling reason to take the new v8 this time around knowing that we're going to have another big round of breakage for the next one?

@Fishrock123
Copy link
Member

we should be fine introducing in 3.1.

It touches a lot of the codebase, I talked to @trevnorris about this and he wasn't particularly comfortable with doing it that way.

@domenic
Copy link
Contributor

domenic commented May 27, 2015

Ah ok, I figured since it was behind a flag the impact would be minimal, but I can believe maybe not.

@trevnorris
Copy link
Contributor

@mikeal

is there a compelling reason to take the new v8 this time around knowing that we're going to have another big round of breakage for the next one?

You mean update to v4.3? If we want to get the new Buffer implementation into the wild then absolutely. We can't until at least that version.

@domenic

Why hold up on Buffer?

I'm trying my best to make sure that doesn't happen. The patch is almost ready for review. Reason is because I'm super (possibly overly) cautious about changes to Buffer. Since so much other code relies on it, any hiccup has a strong ripple effects. And even though it's behind a flag, I've had to conditionally change logic for almost every Buffer method. That's the part that makes me nervous.

But if while under review other maintainers say it's fine for release in a minor then I won't prevent that from happening.

@mikeal
Copy link
Contributor

mikeal commented May 27, 2015

You mean update to v4.3? If we want to get the new Buffer implementation into the wild then absolutely. We can't until at least that version.

We could continue to do that through RC releases of the next branch for now though right?

The thing is, if this breaks the whole native ecosystem this much it won't end up getting much more use than the RC releases get anyway.

@kkoopa
Copy link

kkoopa commented May 27, 2015

V8 4.2 was the update that should not have been taken, especially since it was late already.
Yes, the 64000 packages is from a walk of the dependency tree, it's an upper bound on packages that may need changing something (code or dependencies does not make a difference).

@trevnorris
Copy link
Contributor

@mikeal If V8 isn't being updated then there's no need for a v3.0 release until we upgrade to v4.4, correct?

@domenic
Copy link
Contributor

domenic commented May 27, 2015

I want 4.3 badly to fix many vm bugs #1773. 3.0 now. jsdom wants badly.

@kkoopa
Copy link

kkoopa commented May 27, 2015

Not much wrong with 4.3, but if 3.0 is to be released, it should be in a state where it essentially works with V8 4.4 too, so as to avoid doing all of this again in six weeks. We all already know exactly what is in V8 4.4 and what is not. Essentially, don't release a new major until the next branch has been updated and at least compiles.

@snsparrish
Copy link

Will this include the DNS changes #1843? I'd really like to see that.

@mscdex
Copy link
Contributor

mscdex commented Jun 7, 2015

@snsparrish Unlikely. There are still some things that need to be discussed design-wise and feature-wise.

@rvagg
Copy link
Member Author

rvagg commented Jun 10, 2015

I took a detour on my way to RC builds: #1938, we'll get 3.0.0 out soon!

@Fishrock123
Copy link
Member

I think it may be good to do a 2.3.0 beforehand. #1939

@sandro-pasquali
Copy link

@miketheprogrammer The "developers of products" I'm referring to aren't on this thread. They are the people @mikeal is passionate about:

I’m passionate about people creating things with technology that didn’t find technology accessible before. You can call it democratization or amateurization of technology but what it really means is making the tools to build things accessible to artists, teachers, and whole host of people who just couldn’t participate before. Part of that is making things simpler, easier, and pushing our way up the stack but another part of it is evolving how we build these tools and what it takes to participate in them.
-- http://blog.modulus.io/meet-mikeal-rogers

I share those goals. I think Node (the JS stack) represents a real revolution not just for developers but for citizens, freedom, and capitalism. An unreliable Node depresses that success.

And there is a technical point to be made here, which came to mind while reading Leslie Lamport's recent Turing Lecture "The Computer Science of Concurrency: The Early Years" (http://bit.ly/1GjdHPn). I refer to the following passage:

The omission that would have seemed most striking to someone reading this history in 1977 is the absence of any discussion of programming languages. In the late 1960s and early 1970s, most papers considered to be about concurrency were about language constructs for concurrent programs. A problem such as mutual exclusion was considered to be solved by introducing a language construct that made its solution trivial. This article is not about concurrent programming; it is about concurrent algorithms and their underlying principles.

I really believe locking the STDLIB soon and focusing all efforts on increasing the quality and depth of npm packages is the best way forward. I hesitate to support threads or a new Promise API (in Node core) or anything else that delays stability and degrades predictability. I just hope that many on this list believe the innovation that Node is driving does not descend from the API, but from trust in Node's ability to persist into the long future, and in the kind of high-speed, networked, data-driven software it promotes and simplifies.

Side note: V8 is a Google product whose priorities are Google's priorities.

@mcollina
Copy link
Member

@sandro-pasquali you say really good words about the node community at large. However, the major discussion here is V8, on which we highly depend on. Locking it down (like node 0.10) make little sense from a performance and security point of view. The key point of discussion is here is how to manage this change, which we all feel is inevitable.

@trevnorris
Copy link
Contributor

I forget, should the next branch be rebased on master merge master into next? I can take care of this on Monday.

@bnoordhuis
Copy link
Member

Can I suggest we hold off v3.x a little longer until V8 4.4 goes gold? We're already delayed so much that another week or two won't matter much. I can PR an upgrade to 4.4.

/cc @chrisdickinson

@domenic
Copy link
Contributor

domenic commented Jun 18, 2015

Given that 3.x is blocked on nan and stuff anyway that seems fine. But we should upgrade to 4.4 and get all our ducks in a row so that the moment 4.4 drops we can ship 3.0.0. Hopefully the 1-2 weeks until that happens are enough for nan to get its stuff together.

@ronkorving
Copy link
Contributor

What's the policy on which V8 versions to follow? V8 4.5.x has been shipping with a whole bunch of ES6 features people have been waiting for (arrow functions, just to name my favorite addition).

@trevnorris
Copy link
Contributor

@ronkorving I believe it's still unstable. master branch stays on the stable release.

@ronkorving
Copy link
Contributor

Understood. Sorry, Ben already explained to me how this works. I'll have to be patient :)

@flying-sheep
Copy link

stable means “the version in the currently stable chromium”, right?

that means upgrading to 4.5 can happen once chromium 45 gets stable?

@domenic
Copy link
Contributor

domenic commented Jul 15, 2015

Yes. It just branched https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/14zoZnUu5Oc so I'd anticipate another 6-8 weeks.

@flying-sheep
Copy link

great, one doesn’t see an ETA often in the world of open source!

@mgol
Copy link
Contributor

mgol commented Jul 21, 2015

Chrome 44 stable just went out, which means V8 4.4 is stable.

@flying-sheep
Copy link

4.4 doesn’t seem to have any new ES6 features, though 😊

https://gist.github.com/flying-sheep/02064095595db1f26c11

@mgol
Copy link
Contributor

mgol commented Jul 22, 2015

It does - it adds support for computed properties, computed shorthand
method names etc.

Michał Gołębiowski

@targos
Copy link
Member

targos commented Jul 22, 2015

@flying-sheep true, but it now ships at least two new features:

  • unicode escapes
  • computed property names

@flying-sheep
Copy link

according to the changelog (the thing i linked is simply the filtered original changelog) computed properties are in 4.2 already.

btw i don’t want to argue about anything, i just wanted to show you the filtered changelog since i found it interesting 😄

@mgol
Copy link
Contributor

mgol commented Jul 22, 2015

Maybe the initial code was in but it definitely wasn't enabled by default. They're in 4.4, they weren't in 4.3. The changelog is apparently not 100% accurate.

@flying-sheep
Copy link

got it, thanks!

@brendanashworth
Copy link
Contributor

3.0.0 was released in #2299, closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta Issues and PRs related to the general management of the project.
Projects
None yet
Development

No branches or pull requests