-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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.4.2 #995
Comments
FYI: Jenkins is being a for us and getting different build machines to build on different commits, hiding test failures that crept in before 1.4.1. I also had lots of trouble even getting 1.4.1 out because of this but I think I may have sorted it out (never say never with Jenkins). CI on v1.x as it is now: https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/207/ - expecting to see Windows failures this time. Will try #994 next. |
And there it is! Human error after all, the https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/208/ |
Yay! :) |
2015-02-28, Version 1.4.2, @rvaggNotable changes
Known issues
Commits |
I might just do this today, give me a few hours to work on Jenkins to make sure it's working properly and I'll go ahead and do a release. PLEASE DON'T INTRODUCE SEMVER-MINOR COMMITS UNTIL THIS IS RELEASED |
@indutny @piscisaureus the real problem atm is that Jenkins isn't getting a |
But these look like genuine failures. Or am I missing something? |
@piscisaureus genuine failures but the build is blue (not red), look at the last line:
It's not reporting back. I'm about to hop on one of these machines and investigate whether it's the use of |
@rvagg I'm guessing that the exit code is zero because after the tests, jslint runs and succeds. Batch processing isn't aborted when a command returns a nonzero exit code, So even if there are test failures, the jslint step will run after that and set the exit code to 0. |
@piscisaureus also |
Huh, do you have a jenkins link? vcbuild.bat looks like it does the right thing. |
https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/200/nodes=iojs-win2012r2/console for instance was run with that string. I'm also on one of the servers now running it myself and get the same behaviour. As if |
@rvagg oops. vcbuild.bat is the culprit: https://github.com/iojs/io.js/blob/v1.x/vcbuild.bat#L59 |
confirmed that #988 is fixed in the above nightly build, just doing another CI run because I'm still not happy that vcbuild is fixed, and then will move on to a release if all's good. |
No good, https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/212/ is not happy on Windows. @indutny, you have some work to do, sorry: https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/212/nodes=iojs-win2008r2/console & https://jenkins-iojs.nodesource.com/job/iojs+any-pr+multi/212/nodes=iojs-win2012r2/console - 12 failures on both Windows machines, seem to be focused on tls_wrap. 1.4.2 is going to have to wait some more. |
@rvagg many tests are using |
Ah, I see that it is a pre-requisite... |
Leaves it with 3 failures for me #1003 |
The latter one seems to be triggering some ENOTSUP on writev... @piscisaureus ? |
@indutny libuv-windows doesn't support writev on named and ipc pipes, and will fail with ENOTSUP. Maybe that's causing the failures? |
@piscisaureus I really need to get a release out to deal with the tls-wrap bug, can you give me an assessment of whether it's worth holding it up to deal with these too? If not, then a "Known issues" item would be good but I don't know what that should be; something about "ENOTSUP on writev errors on Windows" |
To be honest I think that the test-child-process-stdio-big-write-end failure is very serious. I can't trivially implement writev() for pipes in libuv, so I would suggest reverting the StreamBase patches for the time being. |
I'm sorry, I don't have an opportunity today to find a better solution ... |
@piscisaureus I doubt it is related to StreamBase. |
@piscisaureus Aaaah, I think you actually talked about StreamWrap::AddMethods... |
@piscisaureus @indutny I have a 1.4.2 built and ready to release and seems to address most of the concerns related to tls, should I just push this out while we find a way to fix things up for a 1.4.3? That's my vote but I really don't understand the details of the other problems. |
Will fix it in a bit. |
OK, my vote: release 1.4.2 now, get a 1.4.3 out ASAP, even if it's tomorrow (or even today?). 1.4.2 much less broken than 1.4.1 for Windows. |
@rvagg I have a fix coming in a minute. |
Only TCP and JSStream do support `.writev()` on all platforms at the moment. Ensure that it won't be enabled everywhere. Fix: nodejs#995
I'm still voting for a 1.4.2 now, it's ready to go, 1.4.3 can be soon after as far as I can see this isn't quite as serious |
@rvagg please put it into known problems then, and let's do a 1.4.3 right after it :) I'm quite sure that people might hit it in their code so releasing fix would be quite important. |
Neither failure is indicative of a serious issue. So +1 on releasing after fixing test-child-process-stdio-big-write-end |
@piscisaureus to clarify: you're -1 on 1.4.2 going out and want test-child-process-stdio-big-write-end fixed before a release? we're in the same situation as 1.4.0 now that this has been tagged and built and ready to release so I can't bundle more in to a 1.4.2. |
going to release 1.4.2, it's tagged and I'm now -1 on deleting tags so may as well get this out and work on 1.4.3 |
https://iojs.org/dist/latest/ it's out ping @iojs/website and not we will have a 1.4.3 soon too |
Agreed, don't delete tags. |
Only TCP and JSStream do support `.writev()` on all platforms at the moment. Ensure that it won't be enabled everywhere. Fix: #995 PR-URL: #1008 Reviewed-by: Bert Belder <[email protected]> Reviewed-By: Rod Vagg <[email protected]>
I don't have access to a computer right now. Cc @therebelrobot / @snostorm / @mikeal |
I'm online, I'll take a look at updating the site |
FYI slight delay as I'm doing this one "right" with a long overdue switch to handlebars for version/v8 version (since I am find/replacing those same fields anyway.) Almost to the finish line. |
Sitting at nodejs/iojs.org#251, I'll ping @iojs/website for a +1 |
Heads up @rvagg I put up a second PR for 1.4.3 as well nodejs/iojs.org#252 |
This is a quick one, will give it 24 hours or less. Mainly to fix #988, proposed change being in #994.
25da0742ee
] - build: improve vcbuild.bat (Bert Belder) #998b8310cbd3e
] - build: reduce tarball size by 8-10% (Johan Bergström) #96158a612ea9d
] - deps: make node-gyp work with io.js (cjihrig) #9902a2fe5c4f2
] - deps: upgrade npm to 2.6.1 (Forrest L Norvell) #99084ee2722a3
] - doc: minor formatting fixes. (Tim Oxley) #996cf0306cd71
] - doc: update stability index (Chris Dickinson) #943fb2439a699
] - doc: add robertkowalski as collaborator (Robert Kowalski) #977f83d380647
] - doc: update os.markdown (Benjamin Gruenbaum) #976ae7a23351f
] - doc: add roadmap, i18n, tracing, evangelism WGs (Mikeal Rogers) #91114174a95a5
] - doc: document roadmap, workgroups (Mikeal Rogers)865ee313cf
] - doc: add tellnes as collaborator (Christian Tellnes) #97301296923db
] - doc: add mscdex as collaborator (Brian White) #972675cffb33e
] - http: don't confuse automatic headers for others (Christian Tellnes) #8287887e119ed
] - install: new performance counters provider guid (Russell Dempsey)4d1fa2ca97
] - src: add check for already defined macro NOMINMAX (Pavel Medvedev) #9861ab7e80838
] - tls: proxyhandle.reading
back to parent handle (Fedor Indutny) #1004755461219d
] - tls: fix typohandle._reading
=>handle.reading
(Fedor Indutny) #994The text was updated successfully, but these errors were encountered: