> ___
> From: Keith Gardner [kreios4...@gmail.com]
> Sent: 11 July 2014 14:34
> To: Kobus Jaroslaw
> Cc:
> Subject: Re: [Development] Adding support for version number comparisons
>
> On Thu, Jul 10, 2014 at 8:47 AM, Kobus Jarosl
On Thu, Jul 10, 2014 at 8:47 AM, Kobus Jaroslaw
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
On Thursday 10 July 2014 07:53:29 Keith Gardner wrote:
> > Currently, the QVersion::compare has an overload to pass a functor that
>
> performs the suffix comparison. Are you suggesting having a "default" in
> the operators that can be overwritten?
No global state, please.
--
Thiago Macieira -
-project.org
[development-bounces+jaroslaw.kobus=digia@qt-project.org] on behalf of
Keith Gardner [kreios4...@gmail.com]
Sent: 10 July 2014 14:53
To: Olivier Goffart
Cc:
Subject: Re: [Development] Adding support for version number comparisons
On Thu, Jul 10, 2014 at 7:31 AM, Olivier Goffart
Jarek
________________
From: development-bounces+jaroslaw.kobus=digia@qt-project.org
[development-bounces+jaroslaw.kobus=digia@qt-project.org] on behalf of
Keith Gardner [kreios4...@gmail.com]
Sent: 10 July 2014 14:21
To: Thiago Macieira
Cc:
Subject: Re: [Develo
On Thu, Jul 10, 2014 at 8:09 AM, Olivier Goffart wrote:
> On Thursday 10 July 2014 07:53:29 Keith Gardner wrote:
> > On Thu, Jul 10, 2014 at 7:31 AM, Olivier Goffart
> wrote:
> > > On Monday 02 June 2014 13:24:55 Richard Moore wrote:
> > > > On 2 June 2014 13:12, Keith Gardner wrote:
> > > > >
On Thursday 10 July 2014 07:53:29 Keith Gardner wrote:
> On Thu, Jul 10, 2014 at 7:31 AM, Olivier Goffart wrote:
> > On Monday 02 June 2014 13:24:55 Richard Moore wrote:
> > > On 2 June 2014 13:12, Keith Gardner wrote:
> > > > On Mon, Jun 2, 2014 at 2:36 AM, Simon Hausmann wrote:
> > > > > I sug
On Thu, Jul 10, 2014 at 7:31 AM, Olivier Goffart wrote:
> On Monday 02 June 2014 13:24:55 Richard Moore wrote:
> > On 2 June 2014 13:12, Keith Gardner wrote:
> > > On Mon, Jun 2, 2014 at 2:36 AM, Simon Hausmann <
> simon.hausm...@digia.com>
> > >
> > > wrote:
> > >> I suggest a name that is more
On Monday 02 June 2014 13:24:55 Richard Moore wrote:
> On 2 June 2014 13:12, Keith Gardner wrote:
> > On Mon, Jun 2, 2014 at 2:36 AM, Simon Hausmann
> >
> > wrote:
> >> I suggest a name that is more centric towards the _function_ of the
> >> class,
> >> comparison of different software versions.
On Sat, May 31, 2014 at 2:00 PM, Thiago Macieira
wrote:
> Em sex 09 maio 2014, às 11:36:08, Keith Gardner escreveu:
> > I have been working on adding a class to QtCore (QVersion) to support
> > storing version numbers, convert to/from QString, and having comparison
> > operators. My goal was to
On Mon, Jun 2, 2014 at 7:33 AM, Jake Petroules wrote:
> On 2014-06-02, at 08:24 AM, Richard Moore wrote:
>
> On 2 June 2014 13:12, Keith Gardner wrote:
>
>> On Mon, Jun 2, 2014 at 2:36 AM, Simon Hausmann
>> wrote:
>>
>>>
>>> I suggest a name that is more centric towards the _function_ of the
>
On 2014-06-02, at 08:24 AM, Richard Moore wrote:
> On 2 June 2014 13:12, Keith Gardner wrote:
> On Mon, Jun 2, 2014 at 2:36 AM, Simon Hausmann
> wrote:
>
> I suggest a name that is more centric towards the _function_ of the class,
> comparison of different software versions.
>
> QVersionInfo
On Monday 2. June 2014 13.24.55 Richard Moore wrote:
> On 2 June 2014 13:12, Keith Gardner wrote:
> > On Mon, Jun 2, 2014 at 2:36 AM, Simon Hausmann
> >
> > wrote:
> >> I suggest a name that is more centric towards the _function_ of the
> >> class,
> >> comparison of different software versions.
On 2 June 2014 13:12, Keith Gardner wrote:
> On Mon, Jun 2, 2014 at 2:36 AM, Simon Hausmann
> wrote:
>
>>
>> I suggest a name that is more centric towards the _function_ of the class,
>> comparison of different software versions.
>>
>
> QVersionInformation was also proposed as a name in the code
On 2014-06-02, at 08:12 AM, Keith Gardner wrote:
> On Mon, Jun 2, 2014 at 2:36 AM, Simon Hausmann
> wrote:
> On Saturday 31. May 2014 15.02.49 Keith Gardner wrote:
> [...]
> > > And then you'd use: QVersion::compare(a, b, myCompare);
> > >
> > >
> > > Big +1 to everything. This approach should
On Mon, Jun 2, 2014 at 2:36 AM, Simon Hausmann
wrote:
> On Saturday 31. May 2014 15.02.49 Keith Gardner wrote:
> [...]
> > > And then you'd use: QVersion::compare(a, b, myCompare);
> > >
> > >
> > > Big +1 to everything. This approach should serve everyones' use cases;
> > > let's get this integr
On Saturday 31. May 2014 15.02.49 Keith Gardner wrote:
[...]
> > And then you'd use: QVersion::compare(a, b, myCompare);
> >
> >
> > Big +1 to everything. This approach should serve everyones' use cases;
> > let's get this integration rolling.
>
> I can agree to that. I will have an update thi
On Sat, May 31, 2014 at 2:09 PM, Jake Petroules <
jake.petrou...@petroules.com> wrote:
> On 2014-05-31, at 03:00 PM, Thiago Macieira
> wrote:
>
> Em sex 09 maio 2014, às 11:36:08, Keith Gardner escreveu:
>
> I have been working on adding a class to QtCore (QVersion) to support
> storing version n
On 2014-05-31, at 03:00 PM, Thiago Macieira wrote:
> Em sex 09 maio 2014, às 11:36:08, Keith Gardner escreveu:
>> I have been working on adding a class to QtCore (QVersion) to support
>> storing version numbers, convert to/from QString, and having comparison
>> operators. My goal was to provide
Em sex 09 maio 2014, às 11:36:08, Keith Gardner escreveu:
> I have been working on adding a class to QtCore (QVersion) to support
> storing version numbers, convert to/from QString, and having comparison
> operators. My goal was to provide an API to assist in the following use
> cases:
>
>- P
Em qua 14 maio 2014, às 13:36:30, Thiago Macieira escreveu:
> QSysInfo::osVersion() will return "Windows 8" but
> QSysInfo::osKernelRelease() will return "6.2.9200".
BTW, on Linux:
$ qtdiag | head -2
Qt 5.3.1 (x86_64-little_endian-lp64 shared (dynamic) debug build; by GCC 4.8.1
20130909 [gcc-4_
Em qua 14 maio 2014, às 14:12:40, Stephen Kelly escreveu:
> Note also that version number schemes for particular software are not
> constant over time.
>
> https://blog.qt.digia.com/blog/2009/09/03/qt-4th-edition-feature-pack-7/
That was a joke! Tongue in cheek with how Symbian/S60 named its ver
On 2014-05-14, at 04:26 PM, Thiago Macieira wrote:
> Em qua 14 maio 2014, às 08:45:28, Keith Gardner escreveu:
>>> Well, if you use a virtual, you'd simply subclass to handle the specific
>>> format for your project.
>>
>> I haven't thought about using inheritance to simplify the compare but I
>
Em qua 14 maio 2014, às 08:45:28, Keith Gardner escreveu:
> > Well, if you use a virtual, you'd simply subclass to handle the specific
> > format for your project.
>
> I haven't thought about using inheritance to simplify the compare but I
> think that would provide the best compromise.
I don't w
Keith Gardner schreef op 14-5-2014 15:45:
Well, if you use a virtual, you'd simply subclass to handle the
specific format for your project.
I haven't thought about using inheritance to simplify the compare but
I think that would provide the best compromise. What are your
thoughts abo
>
> Well, if you use a virtual, you'd simply subclass to handle the specific
> format for your project.
>
I haven't thought about using inheritance to simplify the compare but I
think that would provide the best compromise. What are your thoughts about
comparing a QVersion to a QSpecializedVersion
Keith Gardner schreef op 14-5-2014 14:28:
I think that makes sense, but it would be nice if it would be easy
for the user of the class to extend the version checking himself
for non-numerical sections of the version string. That could be
done in several ways I think, for instanc
On Wednesday, May 14, 2014 07:41:20 you wrote:
> At this moment, the 'v' is optional and if present, will be ignored.
Try to ignore the specificness of that. The only point I was making is this:
Version number schemes change over time in a way you can't predict.
Thanks,
--
Join us at Qt Deve
>
> >1. Numerical groupings should be compared integers instead of
> characters
> >in order to properly allow for "alpha2" < "alpha11".
> >2. Delimiters should only be used to denote groups of content but be
> >skipped during the compare. "alpha" == "-alpha" == "~alpha" ==
> ".alph
>
>
> I think that makes sense, but it would be nice if it would be easy for the
> user of the class to extend the version checking himself for non-numerical
> sections of the version string. That could be done in several ways I think,
> for instance with an API like this:
>
> QVersion
> {
> ...
>
On Sunday, May 11, 2014 13:42:25 Keith Gardner wrote:
> Other comparison rules:
>
>1. Numerical groupings should be compared integers instead of characters
>in order to properly allow for "alpha2" < "alpha11".
>2. Delimiters should only be used to denote groups of content but be
>s
On Tue, May 13, 2014 at 03:31:52PM -0500, Keith Gardner wrote:
> On Tue, May 13, 2014 at 3:06 PM, Oswald Buddenhagen
> 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 argumen
Keith Gardner schreef op 13-5-2014 22:31:
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
On Tue, May 13, 2014 at 3:06 PM, Oswald Buddenhagen <
oswald.buddenha...@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.
> >
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
Em ter 13 maio 2014, às 19:13:56, Oswald Buddenhagen escreveu:
> > If you think the QVersion constructor should be strict, I won't disagree.
> > Then we should have a QVersion::fromUserInput, like the QUrl version,
> > which is lax and has heuristics.
>
> that would work from an api perspective.
>
>
> 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:
>From what I have found, there are some key words that can be used
On Tue, May 13, 2014 at 09:38:03AM -0700, Thiago Macieira wrote:
> Em ter 13 maio 2014, às 18:26:32, Oswald Buddenhagen escreveu:
> > the user has complete control over the input of qversion, and can apply
> > any transformations which his use case may require. also, the effort
> > would be quite t
Em ter 13 maio 2014, às 18:26:32, Oswald Buddenhagen escreveu:
> On Tue, May 13, 2014 at 08:51:09AM -0700, Thiago Macieira wrote:
> > Em ter 13 maio 2014, às 17:47:59, Oswald Buddenhagen escreveu:
> > > the analogy is entirely bogus. the thresholds for usefulness and the
> > > user's ability to man
On Tue, May 13, 2014 at 08:51:09AM -0700, Thiago Macieira wrote:
> Em ter 13 maio 2014, às 17:47:59, Oswald Buddenhagen escreveu:
> > the analogy is entirely bogus. the thresholds for usefulness and the
> > user's ability to manipulate the input into something the qt code can
> > work with are enti
Em ter 13 maio 2014, às 17:47:59, Oswald Buddenhagen escreveu:
> On Tue, May 13, 2014 at 07:43:18AM -0700, Thiago Macieira wrote:
> > Em ter 13 maio 2014, às 11:58:15, Oswald Buddenhagen escreveu:
> > > what is the added value of hard-coding arbitrary policies (and
> > > thereby restricting possibl
On Tue, May 13, 2014 at 07:43:18AM -0700, Thiago Macieira wrote:
> Em ter 13 maio 2014, às 11:58:15, Oswald Buddenhagen escreveu:
> > what is the added value of hard-coding arbitrary policies (and
> > thereby restricting possible use cases) instead of providing a
> > minimalistic solution (or two,
Em ter 13 maio 2014, às 11:58:15, Oswald Buddenhagen escreveu:
> On Mon, May 12, 2014 at 06:25:34PM -0700, Thiago Macieira wrote:
> > Em seg 12 maio 2014, às 12:27:46, Oswald Buddenhagen escreveu:
> > > any a-priori transformations needed to make it actually work with random
> > > versioning scheme
On Mon, May 12, 2014 at 06:25:34PM -0700, Thiago Macieira wrote:
> Em seg 12 maio 2014, às 12:27:46, Oswald Buddenhagen escreveu:
> > any a-priori transformations needed to make it actually work with random
> > versioning schemes are highly specific, and should therefore be left to
> > the user. ar
Em seg 12 maio 2014, às 12:27:46, Oswald Buddenhagen escreveu:
> > >- Plugin loading where there are multiple versions on the same
> > >system.
> > >- File format validation.
> > >- Executing an already installed command line application where the
> > >behavior is dependent on t
>
> > >- Plugin loading where there are multiple versions on the same
> system.
> > >- File format validation.
> > >- Executing an already installed command line application where the
> > >behavior is dependent on the called application's version.
> > >- Performing software inst
On Sat, May 10, 2014 at 03:39:51PM -0700, Thiago Macieira wrote:
> Em sáb 10 maio 2014, às 22:04:26, Sune Vuorela escreveu:
> > On 2014-05-10, Thiago Macieira wrote:
> > > How do you make 5.3.0-rc1 compare less than 5.3.0?
> >
> > we call them 5.3.0~rc1.
>
> And how does "5.3.0~rc1" compare less
>
>
>>1. Usually more condensed than the pre-release.
>>2. Some projects experience multiple "releases" with the same version
>>of software (1.0.0-2).
>>3. Libjpeg and OpenSSL use a single letter to represent a level of
>>security for some software (1.0.0g).
>>
>> openssl actual
On 11 May 2014 02:16, Keith Gardner wrote:
>
>1. Usually more condensed than the pre-release.
>2. Some projects experience multiple "releases" with the same version
>of software (1.0.0-2).
>3. Libjpeg and OpenSSL use a single letter to represent a level of
>security for some s
>
> Anyway, given that this is going to be complex, I propose we make up our
> own
> list and *document* it.
>
> I think that to come up with our own list, we need to identify the tree
different types of suffixes that we are talking about: pre-release, null,
and release. The null suffix is obvious
Em sáb 10 maio 2014, às 15:28:03, Jake Petroules escreveu:
> And what about 1.0.0b2? Wouldn't you expect that to be greater than 1.0.0b?
> The problem with trying to implement one comparison algorithm is that there
> are so many different versioning formats in use (at least, within the
> suffix par
Em sáb 10 maio 2014, às 22:04:26, Sune Vuorela escreveu:
> On 2014-05-10, Thiago Macieira wrote:
> > How do you make 5.3.0-rc1 compare less than 5.3.0?
>
> we call them 5.3.0~rc1.
And how does "5.3.0~rc1" compare less than "5.3.0"?
Anyway, you can't change the version string. Please note requir
On 2014-05-10, Thiago Macieira wrote:
> How do you make 5.3.0-rc1 compare less than 5.3.0?
we call them 5.3.0~rc1.
/Sune
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On Sat, May 10, 2014 at 2:28 PM, Jake Petroules <
jake.petrou...@petroules.com> wrote:
> And what about 1.0.0b2? Wouldn't you expect that to be greater than
> 1.0.0b? The problem with trying to implement one comparison algorithm is
> that there are so many different versioning formats in use (at l
And what about 1.0.0b2? Wouldn't you expect that to be greater than 1.0.0b? The
problem with trying to implement one comparison algorithm is that there are so
many different versioning formats in use (at least, within the suffix part)
that it's nearly impossible to do something that works reason
Il 10/05/2014 21:20, Keith Gardner ha scritto:
Let's not make it that complicated.
I think it IS complicated; there are several established (and sometimes
documented) conventions. Supporting a random one is just going to annoy
people used to any other.
My 2 cents,
--
Join us Oct 6-8 at BCC
Let's not make it that complicated. If the suffix is one character, assume
that it stands for a released version. If the suffix is greater than one
character, assume it references a pre-released version. With this rule,
comparisons will work properly. "1.0.0beta" < "1.0.0" < "1.0.0b".
On Sat,
On 2014-05-10, at 02:11 PM, Thiago Macieira wrote:
> Em sáb 10 maio 2014, às 14:03:10, Jake Petroules escreveu:
>> With all the debate, I'm beginning to think that having distinct formats
>> available to conform to might not be such a bad idea after all (SemVer,
>> RpmVer, Dpkg, Freeform, etc...)
Em sáb 10 maio 2014, às 14:03:10, Jake Petroules escreveu:
> With all the debate, I'm beginning to think that having distinct formats
> available to conform to might not be such a bad idea after all (SemVer,
> RpmVer, Dpkg, Freeform, etc...).
So how do you mean 1.0.0b compare greater than 1.0.0? (
On 2014-05-10, at 01:57 PM, Thiago Macieira wrote:
> Em sáb 10 maio 2014, às 14:26:44, Sune Vuorela escreveu:
>> On 2014-05-09, Keith Gardner wrote:
>>> 2. What semantics should be used for version comparisons? Numerical
>>> segments are more clearly defined but when introducing a non-null
Em sáb 10 maio 2014, às 14:26:44, Sune Vuorela escreveu:
> On 2014-05-09, Keith Gardner wrote:
> >2. What semantics should be used for version comparisons? Numerical
> >segments are more clearly defined but when introducing a non-null
> >suffix,
> >many different methods are being
On 2014-05-09, Keith Gardner wrote:
>2. What semantics should be used for version comparisons? Numerical
>segments are more clearly defined but when introducing a non-null suffix,
>many different methods are being proposed.
> 3. Are there any other versioning semantics that shou
Greetings,
I have been working on adding a class to QtCore (QVersion) to support
storing version numbers, convert to/from QString, and having comparison
operators. My goal was to provide an API to assist in the following use
cases:
- Plugin loading where there are multiple versions on the sam
63 matches
Mail list logo
