[Development] Deprecation/removal model going into Qt 6

[Allan Sandfeld Jensen]

On Sonntag, 2. Juni 2019 10:20:51 CEST Manuel Bergler wrote:
> Am Sa., 1. Juni 2019 um 23:35 Uhr schrieb Kevin Kofler <
> 
> kevin.kofler at chello.at>:
> > Volker Hilsheimer wrote:
> > > The overall goal here is to make sure that we don’t have to carry poorly
> > > designed architecture or APIs around with us throughout the Qt 6 series,
> > > and as long as we care about binary and source compatibility within a
> > > major series, doing what we can for Qt 6.0 (and doing it right) is the
> > > only option we have.
> > > 
> > > Perhaps we can care less about those compatilbiity promises; I
> > > personally
> > > think the "big bang every 7 years” is not giving us nearly as much as it
> > > costs; a continuous flow of carefully managed changes to either would
> > > perhaps make it rather easier for developers to follow along, and remove
> > > those big, painful porting headaches (unless you didn’t follow the Qt
> > > releases, in which case it’s just as bad as it is today).
> > 
> > But the problem for developers is NOT the 5.x releases that do not break
> > the
> > API. Those are great! The problem is those n.0 releases that DO break the
> > API. And the solution there would be to just stop doing this kind of
> > releases. Changes such as deprecating or incompatibly rewriting a data
> > structure as central as QList (as seems to be already consensus for Qt 6)
> > are just a major disservice to developers. ABI breaks such as the QString
> > SSO (that also seems to be already consensus for Qt 6) are also
> > unnecessary
> > and probably also counterproductive in some use cases. And switching the
> > build system for Qt itself to CMake, while still supporting both CMake and
> > QMake for user code (as Qt 5 with its QMake-based build system already
> > does), can be done without breaking source nor binary compatibility.
> > 
> > Your proposal to break ABI at every 6.x minor release would be an absolute
> > nightmare for distributors. It would no longer be possible to upgrade
> > stable
> > releases of a distribution like Fedora to a new Qt as is frequently done
> > now. Rolling-release distros would also suffer, having to go through a
> > coordinated mass transition each time. And third-party PPAs upgrading Qt
> > for
> > a stable distribution would also become harder to offer (because they
> > would
> > have to rebuild ALL Qt-using packages, not just those (ab)using private
> > APIs). I do not see how this would be an improvement over the current
> > situation at all.
> > 
> >         Kevin Kofler
> 
> There are at least two ways Qt and/or distributors could deal with ABI
> incompatible changes in minor releases of Qt 6. First of all, Qt itself
> could make use of inline namespaces to ship several version of the same
> classes in the same binary while keeping source compatibility. And if Qt
> doesn't want to go that route because of maintenance overhead then the
> distributors themselves could decide not to ship just a single version of
> Qt, but rather have multiple versions side-by-side using the custom
> namespace and library infix option already provided by Qt.
> 
> That said, I'm in favor of allowing ABI (and in my opinion even API)
> breaking changes in minor releases, since that allows to evolve APIs
> continuously instead of only once every major release. Right now, even
> though the API and ABI are stable, I have never seen an update to a new
> minor version of Qt5 that did not require source changes due to changed
> behavior, so fixing a few calls that no longer compile doesn't increase the
> cost of updating all that much. As a matter of fact, fixing source
> incompatibilities is in my experience much easier than figuring out why
> behavior has changed, since I don't even have a starting point where to
> look in the latter case.
> 
I have no problem with breaking ABI more often but allowing it in every minor 
releases probably goes to far. Perhaps every second LTS (every 3 years), might 
be better.

'Allan