build: drop support for VS 2013 in v7

[bnoordhuis]

Proposal: drop support for building node.js with VS 2013.

Motivation: VS 2013 has numerous bugs in its C++11 support and in general. The source tree is full of hacks that work around this broken compiler and pull requests sometimes strand on it (e.g. #5458.)

As to add-ons, we could extend VS 2013 support for our public headers for a while (and test that through test/addons) but V8 will probably force us to update the baseline there too. Chromium currently requires Visual Studio 2015 Update 2 so I expect V8 will follow suit sooner rather than later.

[joshgav]

Thoughts @AndrewPardoe @orangemocha @nodejs/platform-windows @mousetraps

[AndrewPardoe]

My opinion: move the compiler forward unless you know of specific reasons not to. VS offers multiple solutions for those who believe they can't move to the latest. For example, you can continue to compile solutions in VS 2015 using the VS 2013 project & build system.

[joaocgreis]

We've been advising to use VS2015 to compile modules for some time, so I don't think this is going to be a big issue for most users. It's good to keep moving forward, and after the issues mentioned above, I think we should do this.

One thing to consider is our release infrastructure, we'll need different machines for VS2013 and VS2015. Could we move v6 to VS2015 before it turns LTS?

cc @nodejs/build

[jasnell]

Given the number of small inconsistencies I've been hitting with vs2013 on things like the url parsing and http2 implementation, I'd definitely be +1 on dropping vs2013 in v7 and forward.

I'm not sure if we could get away with moving v6 to vs2015 exclusively at this point. That would be a discussion for the @nodejs/ctc tho. I certainly wouldn't mind.

[eljefedelrodeodeljefe]

As stated already, definitely in favour. Especially now that build tools are installable through a separate exe headlessly.

Since it's compatible down to XP we could actually set it lower, theoretically.

[jwulf]

Do people still use Windows?

[bnoordhuis]

Save snark for Twitter, please.

I'm not sure if we could get away with moving v6 to vs2015 exclusively at this point.

I personally don't see a problem with that when we're talking about building node from source.

As to add-ons, do we want to commit to supporting a compiler that is five or six years old by the time the v6 LTS branch gets EOL'd? Now that Visual C++ Build Tools exists, taking out a lot of the pain of building add-ons on Windows, I'm inclined to say 'no'.

(The question of support is applicable to older versions of gcc and clang too, of course.)

[jasnell]

@bnordhuis ... good point. Definitely does not seem tenable. Thinking about it further, I think I'd be +1 on transitioning away from vs2013 in v6.

[jasnell]

@nodejs/ctc ... does anyone have any strong feelings about maintaining vs2013 support in v6 and forward? If we do drop it, how do we want to go about messaging it?

[ChALkeR]

+1 to dropping support for any old compiler in the next semver-major (i.e. v7), if that would reduce the number of hacks and/or maintenance costs, as long as that doesn't break any supported platform, or if that is forced on us by upstream (i.e. v8) or if we expect that it would be forced on us in near future.

Note: also +1 as treating any platform that isn't supported by the corresponding upstream as unsupported (e.g. Windows XP, Debian 6, OS X 10.8, CentOS 4, etc.), if we don't already.

No opinion on v6, but I would prefer if the final course of action on that would be decided before v6 goes into LTS mode.

[rvagg]

I'm happy to defer to our Windows folks here, I know that things move a bit differently there than on Linux so perhaps this is perfectly reasonable.

I'm interested in the suggestion that we maintain 2013 support for addons. This seems like a worthy thing to do because putting demands on users to make sure they have 2015 is very different to demanding that of people building from source. However, I'm not sure I see a clear path to actually testing this that doesn't involve some pretty crazy Jenkins gymnastics. @joaocgreis can you think of a straightforward way to build with 2015 but test-addons with 2013?

[orangemocha]

+1 on dropping support it makes the life of core developers easier. It would make sense to do this before v6 hits LTS.

We definitely need to keep supporting building native modules with VS 2013.

[jbergstroem]

I can't really contribute much here. +1 to whatever @orangemocha or @joaocgreis suggests.

[jasnell]

Putting this on the ctc-agenda for a quick discussion. I don't think it's going to be controversial but it's worth a quick check. /cc @nodejs/ctc

[joaocgreis]

I'm not sure if native modules build with VS2013 will be compatible with a binary build with VS2015. There is no good documentation for this, I'll investigate and post what I find.

So, dropping 2013 in v7 seems consensual, and in v6 if modules built with 2013 can be supported. The question is: if native modules build with VS2013 cannot be supported and we have to require all v6 users to move to VS2015, should we still drop VS2013 in v6?

[RReverser]

if native modules build with VS2013 cannot be supported

I don't see why not - they're building native libraries after all, which don't really depend on VS or any runtime. In the same way apps and DLLs that were compiled even for Windows 98 still work on Windows 10.

[orangemocha]

To clarify, we need to ensure that the headers and libs we ship can be compiled against with VS 2013.

Incidentally, there's also a dependency on the Node ABI. And we are aware of at least one case where a module compiled in VS 2015 isn't compatible with an official release of node.exe, which we build with VS 2013.

While we still need to properly solve that issue - hopefully by smoothing the ABI incompatibility - saying "please update to VS 2015" sounds like a better answer than "please downgrade to VS 2013" as a workaround for those issues.

[srl295]

FWIW ICU is considering dropping VS2013 in v58 for the same reasons.

[joaocgreis]

@RReverser DLLs can work fine, if they only pass C data and are careful with linking. But as the issue with node-sass shows, it can have some tricky issues.

@rvagg In CI, addons are already compiled in the machines that run the tests, so it's relatively easy to test this. Here is an attempt: https://ci.nodejs.org/view/All/job/reis-tbw/1/ (no TAP, console shows details). Looks like our addons tests work when compiled with 2013 and node with 2015.

[mscdex]

I'm curious about the Build Tools package(s). Are versions of the Build Tools aligned with VS major releases (at least as far as the compiler and other content included in the Build Tools packages)? If not, will dropping VS2013 support potentially cause a problem for Build Tools users?

[AndrewPardoe]

@mscdex the VC+ Build Tools line up with VS major releases and updates.

[Announcement]

my vote is to wait until v8 support for vs2013 actually happens to go away, or whatever the latest windows 2013 associated release is.

[AndrewPardoe]

@Announcement, VS 2013 support goes through 2019, extended (a common option) is through 2024. Just FYI. https://support.microsoft.com/en-us/lifecycle/search?sort=PN&alpha=Visual Studio

[Trott]

@AndrewPardoe I think they were referring to V8 support for VS 2013 going away, not Microsoft support.

[joaocgreis]

@bnoordhuis also vcbuild.bat, but should probably wait for the adjustment in CI.

There's some work to be done in build, the new machines for the release jenkins, and for CI compiling with VS2013 based on the node version. I'll have it ready before the end of the month, so the v7 test builds can already use it.

[bnoordhuis]

also vcbuild.bat, but should probably wait for the adjustment in CI.

Yeah, I have a couple of cleanup commits ready for when 2013 is dropped from the matrix.

[mhdawson]

It might also be useful to have some messaging so that people who build node have some warning as opposed to their CI's just failing over when the chagne is made.

[jasnell]

I've already been tweeting about it a bit. Just posted another reminder. What I would recommend is adding a note to the Release notes for v6.4 tho. /cc @evanlucas

[joaocgreis]

@jasnell Please use the new job reis-iojs+release for the beta builds of v7 announced in #8503 . That job uses VS2015 automatically for v6 and above.

The plan is to merge it with iojs+release when we start releasing v6 with VS2015. When that happens, only iojs+release will be used for everything.

[saper]

I have posted some proposed way of doing this in the sister bug (#7989 (comment))

[saper]

Some info why we should be doing this carefully: the problem is that the code integrated with node via extensions (various third party libraries like libgit2 etc.) is usually not directly under extension authors control.

It takes some experience to find out some subtle issues thread local storage initialization etc. and this is hard to do in the foreign code.

Most currently written node modules use relatively simple C++ code (especially those written specifically for node). As more third-party libraries will be integrated some of them will used advanced C++ and C++11 features which will lead to some very hard to debug bugs, often appearing on some platform but not on another.

Fortunately node-sass and libsass (the C++ part) are maintained by the same group, so there is possibility to take some ABI compatibility considerations into account, but this is always a very difficult decision ("why can't I use C++ feature XX - because of node linking problems").

I think it pays to have a long-term ABI stability strategy (based on PlatformToolset versioning) and do not let people mix C++ ABI by accident.

[joaocgreis]

Release Jenkins and test CI changed to build v7 with VS2015.