-
Notifications
You must be signed in to change notification settings - Fork 30k
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: v1.2.0 #768
Comments
I also want to land #639 |
I think we should release a candidate in 24 hours and then release the full release in 48 hours so that people can test and find bugs. |
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. |
Is it possible to see #601 landed in time for v1.2.0? |
@Fishrock123 #708 is probably not something that should be rushed. |
Yeah, that's fine. :) |
Damn, it's too late to get Linux Tracing in this release :( 5e825d1 |
@mikeal Uh, that already landed? |
my bad, i was looking at the changelog and didn't see it and I assume the build was already kicked off before it landed :) |
Final build is tonight's nightly. |
Also:
Nightly including all of these changes: https://iojs.org/download/nightly/v1.1.1-nightly201502109681fcacf0/ Consider this RC1. Re #758: I agree with @bnoordhuis that this needs further discussion but my guess is that it's probably close. I've put a tc-agenda tag on it but it'll likely be the TC just listening to @domenic's opinion so if you want to weigh in on it then you should do so in the issue. (If it were up to me I'd treat it the same as an unhandled exception and be done with it, but I can understand how that would mess with people's expectations.) |
@fengmk2 re #493, unfortunately it's not mature enough, I still have some hanging work to do on the node-gyp side for Windows which is at the top of my list for things to do when I finally find a spare block of time (illusive at the moment). Be assured that this is a personal priority for me, it's just not going to make it in time for this. |
@rvagg OK, maybe next release. |
@fengmk2 two stop-gap alternatives:
|
@rvagg Thanks! |
@mikeal It is supposed to be. |
PATIENCE! I'm just writing a Changelog proposal in here in another tab so I can get comment on that, about to start the CI process for this too. |
@rvagg I didn't mean it that way. I just meant that is what the plan was. |
Changelog entry header proposalComments on this prior to release welcome! 2015-02-10, Version 1.2.0, @rvaggNotable changes
Known issues
Commits... |
heh, sorry @BenjaminProgram, I was yelling at @mikeal for being impatient, don't take the tone too seriously, my lame attempt at being funny. This changelog process is turning out to be the most onerous task of a release but I think it's worthwhile. |
does anyone have some metrics on how big the performance gains are in event emitter? |
@rvagg don't forget Linux Tracing in the summarized Changelog :) |
sorry, nightly going out now here: https://jenkins-iojs.nodesource.com/job/iojs+release+nightly/77/, will drop in https://iojs.org/download/nightly/ as v1.1.1-nightly20150211aea9b89b5c (tho I think the one before it will actually be identical) |
@mikeal @mscdex said it was close to EE2. Gains for overall is probably like 50-100% more efficient, speed-wise. See also: #601 (comment) |
@rvagg I already did a nightly tonight.. 76 :) |
thanks for picking that up @mikeal, very much worth mentioning that! updated changelog Also added new commit:
|
@rvagg I didn't take it to seriously. |
waiting for #789, I'm going to do another nightly when that lands just to be sure because I don't want to have to do a 1.2.1 straight away to fix a broken doc build. |
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 |
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:
prototype
property #636 / e7573f9 (assert: don't compare objectprototype
property)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)prototype
property (Vladimir Kurchatkin)The text was updated successfully, but these errors were encountered: