Vincent van Ravesteijn wrote:

> I thought we always wanted to support as many compilers as reasonably
> possible in order to allow newcomers to easily compile LyX and to let
> them contribute. Does it make sense to still support Qt 4.5, but to
> require the last version of the Microsoft compiler ?

BTW I do not think that Qt 4.5 needs to be supported. One could also discuss 
in principle whether support for MSVC2010 is needed, or whether we could 
require 2012.

The most important reason to support C++98 in 2.2.0 is IMHO that a change so 
fundamental as to switch from one standard version to another is always a 
risky thing, and doing it immediately before a release is the worst timing 
one could have. These changes need to be done in the development branch 
directly after a stable release in order to get more experience. This is not 
pure theory, simply by compiling in C++11 mode we did already find a bug in 
a mature, well reputed compiler: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67557 Who tells us that there 
is not another one hidden (maybe in another compiler)?

Since we need to support C++98 anyway it is also clear that MSVC 2010 should 
not be dropped. This eases the work of the windows people a lot: No new 
dependencies are required right now, and nobody needs to learn a new version 
(remember that MSVC is not only a compiler, but an IDE).

Finally, supporting C++98 for 2.2.0 does not cost us anything right now, 
since no biger changes will happen before the release anyway, and the 
existing code supports C++98. Also, those who want to compile in C++11-mode 
can do so as well if they are willing to accept a higher risk. If the case 
happens that backporting a bugfix to 2.2.x will be difficult (as mentioned 
by Guillaume), then we can still see how to solve that problem at the time 
when it happens. IMHO, a backporting difficulty caused by the need to 
support the old standard is in no way different from a backporting 
difficulty caused by some code refactoring. In both cases, one needs to 
assess the importance of the bug fix, the cost of it and its risk. Then one 
can decide whether to do it or not.


Georg


Reply via email to