[Development] How does QML versioning work?

[Alan Alpert]

On Sun, Jul 27, 2014 at 11:59 PM, Koehne Kai <Kai.Koehne at digia.com> wrote:
>> -----Original Message-----
>> From: development-bounces+kai.koehne=digia.com at qt-project.org
>> Subject: [Development] How does QML versioning work?
>>
>> Hi all,
>>
>> We have a very clearly defined policy on what changes are allowed new
>> versions of Qt:
>>
>> - Patch release: Source & binary compatible bug fixes only
>> - Minor release: Source & binary compatible bug fixes and new features
>> - Major release: Incompatible changes allowed
>>
>>
>> What about QML modules? I couldn't find a similar policy outlined anywhere;
>> does one exist?

No separate policy exists. It's the exact same policy for Qt QML APIs
as Qt C++ APIs. At least, it is at the high level described above.

See http://qt-project.org/doc/qt-5/qtqml-cppintegration-definetypes.html#type-revisions-and-versions
for how this gets implemented in QML versions.

The only difference is that QML modules are using divergent version
numbers to Qt (which was originally something that C++ modules were
going to do as well, but I don't think they are right now). So those
rules need to be applied to the QML module version, not the Qt
version. QML modules all move at different rates and the maintainers
can choose to advance faster or slower than Qt if needed.

Speaking as QtQuick maintainer, we are not moving faster or slower
than Qt for the forseeable future. So since QtQuick is at v2.3 in Qt
v5.3, we'll be at v2.4 in Qt v5.4, under the above "Minor release"
constraints. Same policy, different numbers, different implementation.

> I'm not sure it's written down anywhere. Anyhow, that's how _I_ understand the policy so far:
> - The major number is bumped for rewritings (e.g. API is removed, or altered).
> - The minor number is bumped for new API.
> - Fixes that do not introduce new API (behavioral changes) do not require a version change.
>
> Qt Quick modules have to keep the source/binary compatibility promises of Qt, but are otherwise versioned independently.
>
> That is,
> - All import versions have to be supported until a new Qt major release.
> - Qt minor releases might contain new imports, and new import versions.
> - Qt patch releases might contain new import versions, too [1].
> - Import versions do not need to be "bumped" in a Qt release.

This is all correct, although I prefer my explanation ;) .

> Regards
>
> Kai
>
> [1]: There's precedence for this in Qt 4.x times, and actually one of the reasons why a separate scheme for e.g. QtQuick was introduced. Anyhow, it's IMO something best to be avoided.

It is best to be avoided, but there are cases, like in Qt 4.7.4, where
it's the lesser of two evils.

--
Alan Alpert