[Development] Adding support for version number comparisons

[Keith Gardner]

>
>
>>    1. Usually more condensed than the pre-release.
>>    2. Some projects experience multiple "releases" with the same version
>>    of software (1.0.0-2).
>>    3. Libjpeg and OpenSSL use a single letter to represent a level of
>>    security for some software (1.0.0g).
>>
>> openssl actually use a multi-letter suffix once it gets high enough. The
> next version of openssl 0.9.8 will be 0.9.8za.
>

>From what I have found, there are some key words that can be used to
identify if a suffix is a pre-release (alpha, beta, ...).  I would propose
that the existence of these words be used to identify this suffix but still
perform the compare lexicographically.  Also, we should not support the
abbreviated forms since the abbreviated forms collide with single letter
release suffix.

Since the checking for the existence for some keywords could be expensive,
I was thinking about checking for the words when the suffix is being set
and not in the compare operation itself.  This would allow for multiple
compares to occur without the overhead of rechecking the same string.

For release versions, I cannot determine any notation that clearly defines
a release suffix other than not containing the list of keywords mentioned
above.

Other comparison rules:

   1. Numerical groupings should be compared integers instead of characters
   in order to properly allow for "alpha2" < "alpha11".
   2. Delimiters should only be used to denote groups of content but be
   skipped during the compare.  "alpha" == "-alpha" == "~alpha" == ".alpha"
   1. Can be restricted to the first character if this is too broad.

Here is an opinion that I think should be made a rule: lexicographical
compares should be case insensitive.  I don't know of any projects that use
case to denote a specific version but I have seen case change for the same
version.  The biggest example is "rc" where it has been "RC" in some
documentation but delivered as "rc".  I think this would be a good idea,
but changing it to case sensitive would be trivial.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140511/ba4c5b91/attachment.html>