[Interest] VS2013

[Charley Bay]

>>> Would people feel bad if we no longer provided binaries for VS 2010?
>>
>> Many people are still on VS2010 (in fact, I know a not-negligible amount
>> of companies still on VS 2008)
>>
>> Microsoft is releasing too fast for the mid to large corporation.

Felix spaketh:
> Very  true. In fact, i work for one such company. We only just officially
> trashed VS2005 compatibility.
>
> Now i'd like to upgrade directly to 2013. Obviously, we will not move from
> an obsolete 2008 to an obsolete 2012 version. That is just not happening,
> and i would suspect a lot more companies would agree.

I know this thread is anecdotal, but to add to "impressions", agree with Felix:

*- We support field-released MSVC2008+Qt4.8 (and have legacy MSVC2003
that we will remove soon)

*- We skipped MSVC2010 and MSVC2012 (they had issues for our use, we
see that they are now "a thing of the past", we have no interest in
them)

*- We are moving to MSV2013 (we see significant benefits for OS
updates, C++11, future vendor support)

So, I selfishly only care about MSVC2013 for Qt5+.  Please keep the
32-bit binaries (at least for now).

I'm running MSVC2012+Qt5.1 currently (to get a "head-start" on the
porting/API issues), but we won't ship that configuration.  We will
ship MSVC2013+Qt5.2 or later.

> If you upgrade, then to the latest version, so the latest version should be
> supported.

I understand that there is some "lag" between MSVC being released and
it getting full tools support.  I'm still quite bloodied-and-bruised
by the unhappy surprises for being, "the first kid on my block with
MSVC2010".  I don't know how "big" the lag for Qt-binaries should be
for the new compiler, but I expect it should be non-zero.  I know many
companies refuse the new compiler until SP1 (usually about six months
later), and I'm inclined to agree (or at least I understand why they
wait).

MSVC2013 is an exception because IMHO, MSVC2010 and MSVC2012 had
serious deficiencies (we won't use them).

> Is it really that much work to maintain three different VS versions?

I understand that there must be some "sparse-matrix" of supported
configurations, and that can be expensive.  It's 32-bit and 64-bit for
the later compilers, multiplied by the OpenGL configurations, and I
understand that "adds up" to demands on the build/test hardware.

--charley