[Development] Adding support for version number comparisons
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
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