[Development] Adding support for version number comparisons

Keith Gardner kreios4004 at gmail.com
Tue May 13 22:31:52 CEST 2014


On Tue, May 13, 2014 at 3:06 PM, Oswald Buddenhagen <
oswald.buddenhagen at digia.com> wrote:

> On Tue, May 13, 2014 at 12:59:10PM -0500, Keith Gardner wrote:
> > > 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:
> >
> i mean much more than suffixes:
>
> post-3.5.1 (fail, everything's a suffix)
>
There has to be some restrictions on tokenizing a version number.  Except
using this format in a conversation context, can you provide an example of
it used as an application or library's version number.  I am not trying to
be argumentative, I want to understand your perspective in context.  I have
never seen it before.


> 4:2.4.5 (fail, colon was not a valid number separator last time i
>         checked)
>
This one has been requested by Thiago and Sune.  Thiago said to skip it if
it will clutter the API but I can add it since it is a part of two
different specs (rpmver and dpkg).


> r12345 (fail, you hardcoded only 'v' as a skippable prefix)
>
Does r stand for "release version" or "revision"?  In this case, there is
not enough context to determine the intent behind the use of 'r'.  In the
case of 'v', there is less ambiguity.


> and these are just the examples i'd call "sane".
>
> my point is that this class is becoming unreasonably complex for a
> rather trivial thing, which only a fraction of the applications will
> use.
>
Your argument is backwards, the problem is complex and the approach is
simple.  You have spent many emails arguing that there are many different
methods of version numbers and that we cannot satisfy all of them.  I agree
that only a fraction of the applications will use this API, but that is
still greater than zero.  In my applications, I heavily rely on version
number comparisons.


> imo, the cases which are fully under the user's control (internal
> version checking) should be handled solely numerically (even without
> considering any pre-releases), which basically means a minimalistic
> semver(-like) implementation which can be fully inline (or even just a
> collection of macros). in this segment, it is entirely unreasonable to
> try to support existing users with bizarre versioning schemes, because
> they most likely already have their own solutions. and new users can be
> told to use the straight-forward system.
>
With that perspective, we can accomplish that now by just dropping the
suffix, which was what my initial proposal for QVersion was.  The request
to include suffix information came from the reviewers and this mailing list.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140513/a7a433e6/attachment.html>


More information about the Development mailing list