[Development] Adding support for version number comparisons

[Keith Gardner]

On Thu, Jul 10, 2014 at 8:47 AM, Kobus Jaroslaw <Jaroslaw.Kobus at digia.com>
wrote:

> Hi All,
>
> With the current state of QVersion (patchset 35) I see the following
> issues:
> 1. operator<() doesn't take the suffix into account (mentioned below)
> 2. There is no handling of sub version (you cannot differentiate 5.0.0,
> 5.0 and 5 - they are all equal)
>
> The idea which could resolve these issues would be not to keep the suffix
> inside a QVersion class. I understand that there is a need for version
> numbers consisting of some labels for preliminary versions. That's why the
> idea is to provide a mechanism for preliminary versioning system in first
> place, and then resolve the labels problem with a simple number/string
> substitution.
>

The problem is that the suffix does not represent just preliminary
versions.  Some projects use the suffix to represent releases as well.
 E.g. OpenSSL 1.0.1h  Other projects store the git SHA in the version
suffix that has nothing to do with the version number.

The conclusion was that the suffixes are semantic dependent and there are
too many semantics out there to come up with one solution. Simple
number/string substitution implies that there is a version semantic already
in place.


>
> The mentioned mechamism for preliminary versions would operate also on
> numbers, but one segment of the QVersion would be distinct. This distinct
> segment (call it preliminary segment) would be the indication for the
> comparator to treat that segment (and followed segments) in a special way
> (i.e. if we compare the preliminary segment with normal one, we say that
> preliminary is always less than normal one, even if its numerical value is
> greater). For now, in QString version for a QVersion, I will use "*" for
> this distinction.
>
> Example:
>
> All below are preliminary versions:
>
> "5.4.0.*0" - the very first alpha version for the upcomming "5.4.0"
> release.
> "5.4.0.*1.1" - beta 1 release
> "5.4.0.*1.2" - beta 2 release
> "5.4.0.*2.1" - rc 1 release
> "5.4.0.*2.2" - rc 2 release
>
> And finally there is:
>
> "5.4.0" - we plan to release that, no preliminary marker
>

How would this handle an alpha release marker as mentioned above?  Also
would "-alpha" and "alpha" have the same weight or would one have priority
over the other?

There are also projects that use a suffix of "-1" to indicate a second
release with the same version number.  How would the number/string
substitution support this?


>
> Later, we prepare for "5.4.1", we release in meantime:
>
> "5.4.1.*0", and so on...
>
> So, I propose to keep inside QVersion only segments and index of the
> preliminary segment, and drop suffix.
>

I do think your approach has its merits but it makes too many assumptions
about how the suffix is structured.  Check out Semantic Versioning (
http://www.semver.org) and compare how they structure their suffixes to
some of your assumptions.  I want to emphasize the examples in Rule 10 show
how crazy the suffixes can be and how some of the content cannot be used in
ordering.

You do bring up some good points and I will need to think on them for a bit.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140711/f02d1096/attachment.html>