[Development] Adding support for version number comparisons

Keith Gardner kreios4004 at gmail.com
Tue May 13 19:59:10 CEST 2014

> but then there is also the semantical perspective. keith's last proposal
> i saw considered only numerical segments specially.

Did you intend to say suffix?  What I wrote on May 11th spoke specifically
to the suffix compare:

>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

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.

Even with numerical segments, the current implementation supports decimal,
hexadecimal, and octal.  Even with Semantic Versioning, numerical segments
by definition can only contain numbers, anything else will be included in
the suffix.

but some versioning
> schemes may treat letters in a numeric way (aa > z). heck, there are
> projects which use hexadecimal notation. there is just no way to make an
> universal internal representation of that, which means the class' main
> purpose (comparing versions) cannot be satisfied.

I also stated "I am not proposing that we support every version number
policy out there but what is the most common cases so that we can cover the
majority."  There are a lot of semantics out there that contradict each
other and only those projects can compare their own version numbers

There is also the detection of pre-release versus release that needs to be
dealt with.  I proposed a way of handling that in a way that is generic and
covers the majority of the software.  Beyond that, we cannot know the weird
policies that the project is using, so we need to provide a comparing
mechanism that can deal with the majority.

There is no issue in saying that if a developer cannot use this class for a
niche versioning semantic, they are welcome to use a different solution.
 This is true about threading, networking, dbus, etc...

Also, keep in mind that the numerical segments have a higher priority in
the compare than the suffix.  This issue is a specific case where the
numerical segments are deemed equal and need to check the suffixes to
complete the compare.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140513/af4d08e7/attachment.html>

More information about the Development mailing list