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 it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development