[Development] Proposal: Deprecate QVector in Qt 6

[Edward Welbourne]

On 4/23/20 11:10 PM, Vitaly Fanaskov wrote:
>>>> Moving to one year release approach doesn't equal to make Qt less
>>>> stable.

> Ville:
>>> Of course it does, if we now allow API breaks every year.

On Fri, 24 Apr 2020 at 13:38, Edward Welbourne <edward.welbourne at qt.io> wrote:
>> Not necessarily: if we *allow* API breaks every year *but* are
>> restrained in our use of them - so that, in fact, over a given ten
>> year period, we only make as many API breaks; we just spread them out
>> over time more evenly - then we'd be no less stable; and it'd be
>> easier for client code maintainers to keep up with our major version
>> updates, because they'd be smaller.

Ville Voutilainen (24 April 2020 17:23)
> That is still less stable. The more frequent the API breaks are, the
> less stable the API is. The size of the API break matters as well, but
> that's easier to control; I make the decision whether to jump now or
> later, and the size of the break to a large extent affects what the
> schedule of the jump is, not that much whether to take a jump (unless
> it's so large as to be over the breaking point, of course).

But there's the catch: at present, it looks like most of our major
versions break API so much that many projects take significant time to
make the updates; converting from Qt5 to Qt6 shall be A Big Deal.  If
the API breaks were spread out over time, so that they don't all happen
at the same time, the ones that require trivial effort from a project
wouldn't bother them, they'd just take them as they go.  Those requiring
more effort will be delayed, but they'll be manageable and not mixed up
with a bunch of other API breaks, so can be handled one at a time.

The initial update of a codebase in response to a third-party library's
API changes is apt to leave some mess - various places where kludges and
short-term solutions were used to complete the update - and it takes a
few months to pay off that technical debt.  Once that's done, the
codebase is clean and orderly again - and ready to cope with the next
API change to come along.  However, if the API breaks come along at the
same time, the kludges and workarounds used to cope with one can tangle
badly with those used to cope with the other; if there's no time in
between the upheavals - because the API breaks all come in one huge load
together - that can result in a nasty snarl.  Such a snarl may be too
much to cope with by refactoring, forcing a significant rewrite, which
is when the project is going to ask itself: do we still want to continue
using this third-party library ?

> If I'd need to consider such a jump every year, I'd switch to
> something else, including changing the programming language if need
> be. Annual API breaks are untenable for any product that has a limited
> budget.

Only if those API breaks usually break the product in question.  If each
is manageable on its own - possibly after a few months of preparation
and refactoring - then the update to a new yearly release is practical
and they never drop behind by more than a year.  My limited
understanding is that, at present, many projects take a long time to
update to each new major release of Qt.  The leap is a high-jump that
some never get over and others have trouble preparing for.  Replacing it
with several modest-sized hurdles would make it possible to keep up at a
steady pace.

While yearly updates may be too frequent, I do think we could benefit
from having Qt major versions a little closer together.  When we notice
a significant API break we'll want to defer to our next major version,
we should think about how soon we can have a major release, so that its
*only* significant API break is that one, rather than saving API breaks
up to make several at the same time.

All, of course, subject to the assumption that we don't make more API
breaks per decade,

	Eddy.