Repository navigation
Release proposal: v1.2.0 #768
Description
Activity
I also want to land #639
right, well this is basically a notice to that effect, the next two nightly will be RC1 and the one after that will be RC2 just before a release if everything goes well.
How about #493 ? It is depended by nodejs/node-gyp#564
#760 is a moderately serious regression, albeit not a new one (introduced in v1.0.2) and doesn't need to hold up the release.
Should we get a fix for #708 in? (the original bug for the dns.lookup thing)
Some people in irc wanted to see #758 land in this.
@Fishrock123 it's far from being done
@vkurchatkin If there is still something to do in the PR, you should say it. I was under the impression that it is now ready.
I'm very interested in landing #758 already and it would be great if it was included in 1.2 - I'm also under the impression that it's done. If there are any issues with it please do speak up.
@vkurchatkin other than the two "no curly braces for one-line bodies" is there anything else holding back this PR? If those are fixed from your perspective can it be merged?
@benjamingr I'm very interested in this too, and that is why I think it's important to do it right
Scanning through the comments, it looks like #758 warrants some further discussion. I'd like to hold off on merging it for now.
@vkurchatkin my point is that assuming we don't specify a default handler and don't specify super precise timer control for #758 we can merge it now and improve these later. Merging it now is just introducing two events to process - it's the most minimal change required and it's immensely useful without getting dragged into breaking changes like adding a default action handler which will cause a lot of debate.
I think that tackling these hard questions (default action and more precise scheduling) can and should be deferred to a later point in time while we can still gain the vast majority of the benefit without sacrificing any future compatibility right now. It will also give us time to evaluate how users choose to deal with unhandled rejections.
Also although it's obvious I'd like to point out you've been immensely useful with this - the feedback you've been providing has been very valuable here.
what you call "precise scheduling" I consider the most important part. If users decide to throw in event handler (and I guess a lot of them will) changing this behaviour might cause unexpected crashes.
28 remaining items
https://iojs.org/download/nightly/v1.1.1-nightly201502117e2235aebb/ if anybody would like to test binaries
new errors page: https://iojs.org/download/nightly/v1.1.1-nightly201502117e2235aebb/doc/api/errors.html
sorting out some armv6 problems, on to release after that ..
OSX pkg installer looks good
x64 msi looks good on win7
Tagged @ 69b5922
Building release @ https://jenkins-iojs.nodesource.com/job/iojs+release/22
@iojs/website 1.2.0 will land in 15 minutes or so if this goes well.
cancelled, I didn't migrate my minor Jenkins settings changes from nightly to release, done that now and restarted @ https://jenkins-iojs.nodesource.com/job/iojs+release/23/
done https://iojs.org/dist/v1.2.0/
will promote armv6 when it's finished
@Fishrock123 The EE2 discussion was something different, it's definitely not as fast as EE2 when it comes to removing events because EE2 just does
this._events[type] = nullinstead of doing an actual delete (which deleting is the better behavior, even at the significant performance cost). However, EE2 is missing out on some of theemit()and other improvements, so we should be faster than EE2 in non-remove*Listener(s) benchmarks.Pushed to website: nodejs/iojs.org@5d270a7
Website changes do not appear to be propagating.. ?
@Fishrock123 git upgrade on the server made it more picky about needing a .gitconfig in order to proceed (not sure why that's necessary). Fixed now, thanks for letting me know!
We have to jump straight to 1.2.0 for this because of:
One might also argue that this qualifies too:
prototypeproperty #636 / e7573f9 (assert: don't compare objectprototypeproperty)I'm also going to turn on the ARMv6 build slave for releases, it's been churning out nightlies with success but this will be the first proper release that will have Raspberry Pi (and other) compatible binaries!
npm changelog is in #738.
I propose we cut this release within 48 hours.
Full commit log since v1.1.0
isPrimitive(Vladimir Kurchatkin)prototypeproperty (Vladimir Kurchatkin)