Would anyone miss Visual Studio 2013 support if it was gone? about units

[MikeGitb]

Considering, that the community editions of VS2015 and VS2017 are freely available and VS2013 comes nowhere close to full c++11 support I'd guess that most people have switched to a newer version of VS by now. The question is also, if there are any important features/bugfixes in the pipeline for the next versions that the remaining VS2013 users would be cut-off from or are they more nice-to-have things? After all it's not like a VS2013 user can't use your library anymore once support is dropped - he just can't use the new versions of it.

[stefan-muc]

@nholthaus Thanks for your long reply! I fully understand it, keep going this direction!

Oh yeah, I tested v2.3.0 RC 2 and it indeed is a lot faster. I like it, thanks!

[mwu-tow]

I'm fine with leaving only VS 2015 support.

[JaapAap]

While I personally would not care, it is hard to speak for 'anyone'. When there is a clear advantage in dropping support, and effort can be better focussed when doing so, that would clearly support your 'drop unless' approach

[nholthaus]

Basically it's getting exponentially harder to maintain, as VS2013 suffers from an abundance of "internal compiler error" bugs, and continued support often relies on using obtuse template syntax that contributors tend to "fix" in their PRs. If none of my (active) users seem to care, then I'll probably support it as long as I don't have to go out of the way to do so, but if some c++14 feature kills it, then so be it.

[stefan-muc]

Yes, here am I! I would miss it as I still use Visual Studio 2013 compiler. If you have a larger codebase with several developers, you usually don't switch compilers too often, because you would have to change your complete infrastructure (including build servers), so there am I with Visual Studio 2013

On the other side I don't see why you should have exponentially harder work by supporting a four year old compiler with new features of this library. There's just one thing I would really miss: Reduced compile time which is already checked in for 2.3.x (I didn't test it, just read the commit log). With 2.2.0 on Visual Studio 2013 I have compile time of around one minute, that's too much.

My recommendation would be:
Develop and release 2.3.0 with reduced compile time but Visual Studio 2013 support. Do a "feature freeze" for 2.3.x
Start a new version (2.4.x / 3.x) without Visual Studio 2013 support and new features.

I want to thank you for you library! To use the words of a friend of mine: "that's crazy shit"
Sadly I can't yet use the literals, but even the other parts of the library are amazing! Thank's for Visual Studio 2013 support.

[nholthaus]

@stefan-muc OK, good to know someone cares :) Thank you and your friend for the kind words!

The reason it's harder in Visual Studio 2013 is not the compiler's (relatively young) age, but that it's not C++14 feature complete, and is incredibly buggy in its C++11 implementation, with the result that valid units library code often causes "internal compiler errors" on vs2013 that don't appear in vs2015, gcc, clang, etc... and the workaround is usual to write very archaic template code that either takes days to figure out the magic combination, or doesn't exist at all.

At this point I'm not doing anything to specifically support, or not support vs2013. I expect it to be supported in v2.3.0, but that's probably it. I understand your logic about switching compilers (the only reason it ever supported 2013 because it's what I was using at work at the time).

I'd also strongly recommend that you use v2.3.0 RC 2 for your current development. It compiles a lot faster, and the only difference between this and the impending official v2.3.0 release is a documentation upgrade, and maybe some additional compile-time speedup if I can figure out something that studio can compile. In terms of testing/QA, it's had the same treatment as all the other releases.