[Development] Adding support for version number comparisons

Keith Gardner kreios4004 at gmail.com
Tue May 13 01:52:31 CEST 2014

> > >    - Plugin loading where there are multiple versions on the same
> system.
> > >    - File format validation.
> > >    - Executing an already installed command line application where the
> > >    behavior is dependent on the called application's version.
> > >    - Performing software installations and updates.
> > >    - QMake support for version number comparisons.
> >
> > Four of the five of those require parsing input that other people create.
> >
> this is rather obviously a no-win situation.
> the only use case for an actual class i buy is the first one (and maybe
> the fourth one), which can be cleanly implemented with a minimalistic
> implementation of semver.

I would say that scenario two does exist but it is a rare one.

Scenario three has come up more than once for my own projects.  It also
ties in closely with scenario 5.  For example, I want to enable c++11
features in gcc if the version number is 4.4 or greater and c++1y features
in versions 4.8 or greater.  First, you have to call "gcc --version" and
parse the result.  Then you have to manually perform the version
comparisons in an unreliable fashion.  I have done this in CMake easily
since it has limited version number comparison functionality but the
features are lacking in QMake.

Scenario four applies to the Qt Installer Framework very pointedly.

> independently from that, we can implement a plain natural compare
> function for strings (which treats groups of digits as numbers, not as
> unicode values).

This would depend on if the normal use case is to compare pre-release
versions against released versions.  If this is, we need to hear it on the
mailing list.  So far, at least four developers have shown a desire for
this use case.

> any a-priori transformations needed to make it actually work with random
> versioning schemes are highly specific, and should therefore be left to
> the user. arbitrary policies totally do not belong into a generic
> low-level class in qtcore.

Could you please describe specifically what parts from my previous email
are deemed random.  I would agree that the one labeled "my opinion" could
be deemed random and if there was a strong disagreement with it, I would be
willing to compromise.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140512/0e7b69c6/attachment.html>

More information about the Development mailing list