>>> 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 _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
