On Thursday, 1 April 2021 07:50:31 PDT Scott Bloom wrote: > That doesn’t mean that Qt cant support it, its that Qt needs to be able to > compile without it. And if you cant, rev the major version
As explained, that's not the driver for major version number. We rev the major number only and exclusively for binary and source compatibility breaks. This policy will not change. We also need to drop compatibility with things that are too ancient and thus are hampering further progress in other areas, making them economically and practically unfeasible to support. Roland is asking we don't, but it's simply not an option for the Open Source project. So we have two choices: 1) do it within a major series 2) do source- and binary-compatibility breaks more often I see you are asking for #2. But as I mentioned before, it appears to be only a convenience of numbering. Meanwhile, doing source- and binary-compatibility breaks has huge implications for the entire ecosystem, so doing it more often means the ecosystem will be harmed. It's not a choice we can make. And as a nefarious side-effect to what you're asking, allowing source- compatibility breaks more often (say 3.5 instead of 7 years) means you get more of them over a fixed period of time, which means that an 8- to 15-year support project would need to go over not one or two, but two to four major API changes. So, I hear you, but I don't agree that what you're asking is the best choice. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest