[Development] Adding support for version number comparisons

Thiago Macieira thiago.macieira at intel.com
Tue May 13 03:25:34 CEST 2014

Em seg 12 maio 2014, às 12:27:46, Oswald Buddenhagen escreveu:
> > >    - 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.

I'd say it's an open-ended situation, with certain conflicting cases. 
Supporting real-world situations are often like that. 

When I implemented QNetworkCookie back in 2007, I followed the spec. That was, 
of course, short-sighted since web servers and web apps send all kinds of bad 
cookie data. So we adapted to the real world, found BKMs from other projects 
and made it work.

I think this is a similar case.

> 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.

About the second case: file formats should have version numbers as full 
integers. Good examples:

moc: #elif Q_MOC_OUTPUT_REVISION != 69
binary QJsonDocument
ELF (binary)

Bad examples:
uic: <ui version="4.0">
XML: <?xml version="1.0" encoding="UTF-8" ?>

But real-life proves me right.

I agree with Keith to the other ones (see his reply).

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

We should. Can QCollator do this?

> 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.

It's only random if we write the randomness (i.e., random sort).

You meant arbitrary. That means we made a choice on what to do. That's what I 
am proposing: we make our informed decision about what to do and then document 

Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

More information about the Development mailing list