[Interest] Interest Digest, Vol 114, Issue 38

[Thiago Macieira]

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