charleyb123 at gmail.com
Thu Dec 12 23:19:27 CET 2013
>>> 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.
> 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
*- 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
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
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.
More information about the Interest