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