[Development] Adding support for version number comparisons

[Oswald Buddenhagen]

On Tue, May 13, 2014 at 03:31:52PM -0500, Keith Gardner wrote:
> On Tue, May 13, 2014 at 3:06 PM, Oswald Buddenhagen <oswald.buddenhagen at digia.com> wrote:
> > 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. 
>
that's besides the point.
by trivial i mean that the concept of version numbers as such is pretty
trivial, and individual implementations are generally quite simple and
short.
but exactly because the concept is so fuzzy, there is simply no
reasonable way to make a solution that comes even close to being
universal. this is a huge red flag. just don't go there.

> 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.
>
it would seem that the code is already where it should be.

> > 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.
>
yes. you actually had me convinced that this would be a useful addition.

> The request to include suffix information came from the reviewers and
> this mailing list.
>
scope creep.