On Tuesday, 12 March 2019 08:56:58 PDT Dr.-Ing. Christoph Cullmann wrote: > > Advantage of this method is that we always get the latest, with latest > > security fixes. If there are futher fixes that apply to users of Qt, then > > all they need to do is rebuild. They will see clearly what those > > libraries are. And it simplifies our own maintenance, of course. > > > > But yes, a disadvantage is now having to deal with the buildsystem for > > those libraries. > > As long as there is at least the idea to have some "helpers" to get external > stuff build, that is fine.
The current idea is to use vcpkg to automate building from sources (yes, even on non-Windows). Whether we continue down that path will depend on how well it's working. > > RHEL 7 was initially released in 2014. If you can't update to a 6-year-old > > series in 2020 when upgrading a major Qt, you could have much bigger > > problems. > > > > I'd also advise looking into RHEL 8, which should be released this year, > > for further long-term support. > > This will be no option, some of our larger customers will stay on 7 for > the next X years. And yes, staying with some LTS Qt is no real solution, > we had already in the past the issues that old Qt releases lacked critical > bugfixes (critical for us, not necessarily for all people). We'll have yet one more LTS Qt before 6.0: 5.15. I also expect that to be even longer term supported than the other ones. My point was only about 6.0 itself: when you do take that plunge, I recommend a full upgrade of everything else to. No, it won't be required. This is just what I recommend. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
