Jean-Marc Lasgouttes wrote: > Le 27/03/2016 21:38, Uwe Stöhr a écrit : >> As I just wrote in the other thread I prefer Qt 5.6. >> I can nevertheless release RC1 with Qt5.5.1/MSVC2010 and also a Qt 5.6 >> version. However, for the final release I won't maintain/offer support >> for a Qt 5.5.1 build. Due to lack of time I will have to focus on one >> version and Qt 5.6 offers a long term support, meaning I can assume that >> this version will be supported by the Qt people for the full life time >> of LyX 2.2.
If you don't have the resources to do two builds (which I can perfectly understand), then you can as well use MSVC2010 and qt 5.5.1 for the whole life time of LyX 2.2. The only thing you need to ensure is not to delete the MSVC and Qt installation on your development machine. Then you will be able to build any upcoming 2.2 LyX version. If you have a hardware problem and cannot use your machine anymore we can still decide what to do when this happens. Switching to MSVC2015 for LyX 2.2.x would not be worse than switching right now, it would recieve a similar amount of testing. > Long term support is about what happens for the coming years. > > Separate builds is more about understanding quickly what bugs come from > the compiler or Qt. I do not anticipate this being needed after 2.2.1. > > This is your choice anyway. But then you'll have to cope with the > windows specific bugs that we may have, with fewer hints about what goes > wrong. IMHO this is not the choice of Uwe alone. The windows installer is provided under the name of the LyX project, as the official windows build, and not as a third party contribution. Therefore, if the installer contains a buggy build, it will damage the reputation of the LyX project. To avoid misunderstandings: I do not say that Uwe did not test thoroughly, or that the build _is_ buggy, but experience tells that there is a certain risk that it _might_ be buggy if only one person did test. > What is nice with Linux is that we do have naturally this diversity > (Qt4/Qt5, gcc/clang). > > On the bright side, chromium has been ported to VC++2015 and several > compiler bugs have been fixed in the process: > https://randomascii.wordpress.com/2016/03/24/compiler-bugs-found-when-porting-chromium-to-vc-2015/ This is one side of the story, and at a much smaller scale we made similar experiences: http://www.lyx.org/trac/changeset/34858/lyxsvn or https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67557. The other side of the story are application bugs which are uncovered by new compiler versions. We had those as well when we introduced clang support. Finally, there are cases where we do not know whether it is a compiler issue or a LyX bug, like http://www.lyx.org/trac/ticket/9892 or http://www.lyx.org/trac/ticket/10009. Building the official 2.2.0 release with MSVC2015 would really make me nervous: - We would throw away all windows specific testing effort of the beta testers. - There is a mysterious crash with the MSVC2015 http://www.lyx.org/trac/ticket/10009 which does not happen with a merged build. Since we do not understand why a merged build "fixes" the crash we do not know what other problems might be created by the same cause. - We would ignore standard best practice in professional software development (which would be to switch compilers at the beginning of a development cycle, not right before a release). If we build 2.2.0 with MSVC2015 we should label the windows build as experimental IMHO. Georg
