[Development] Adding support for version number comparisons

[Kobus Jaroslaw]

> _______________________________________
> From: Keith Gardner [kreios4004 at gmail.com]
> Sent: 11 July 2014 14:34
> To: Kobus Jaroslaw
> Cc: <development at qt-project.org>
> Subject: Re: [Development] Adding support for version number comparisons
> 
> On Thu, Jul 10, 2014 at 8:47 AM, Kobus Jaroslaw <Jaroslaw.Kobus at digia.com<mailto: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.
> 

Yes. That's why I leave transforming of exact suffix version into a numerical version (and vice versa) for the user. Then comparison is done on simple numerical format, and there is no need for user to write his comparator.

Of course, in addition we could try to think of a sensible substitution for not-preliminary versions, too, to handle OpenSSL 1.0.1h -like cases.

> 
> 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?

In my implementation "-" has the same meaning as "." - it's just different kind of separator (format arg of some methods). If you would ask e.g. "alpha" vs "=alpha", then it's just treated as a different label. Important is only position on the passed list, e.g.:

QString versionFoo("5.4.0.*0");
QString versionBar("5.4.0.*1");

QStringList myProjectSemantic << "alpha" << "=alpha";
QStringList yourProjectSemantic << "=alpha" << "alpha";

versionFoo.toString(myProjectSemantic); // would result in "5.4.0.alpha" - we take index 0 from the stringlist
versionFoo.toString(yourProjectSemantic); // would result in "5.4.0.=alpha"

versionBar.toString(myProjectSemantic); // would result in "5.4.0.=alpha" - we take index 1 from the stringlist
versionBar.toString(yourProjectSemantic); // would result in "5.4.0.alpha"


> 
> 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?
> 

As mentioned above, "-" is a different separator - not sure if it will work for you. If your release is 5.4.0 and then you have 5.4.0-1 it would mean it's the same as 5.4.0.1 with a different formatting.

> 
> 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.

OK. Will analyse it later more. With a quick look the current implementation also doesn't fulfil all requirements from this document, so I just wonder which of them are the most important for us. (Example: there can be separate label for preliminary version, and separate suffix for build number - AFAIRC we support only one suffix). 

> 
> You do bring up some good points and I will need to think on them for a bit.

Cool!

I think keeping the class simple (only numeric comparisons) and some kind of smart substitution mechanism would be a really sensible way to go. In any case, even if the user has a very crazy semantics, all of his versions had to be released in some order, so there must always exist a proper number for each of them. Substituting these numbers with suffixes should be done by the user in a most painless way for him.

It would be really nice if we get one common version of the QVersion, so that it could be used in the future version of installer framework.