>
> 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
Dear all,
I've configured my pro file in order to add to the Bundle the icons and
launch images.
I use the system:
IconFiles.files=$$system("find $$PWD/icon/ios/ -name '*.png'")
IconFiles.path=./
QMAKE_BUNDLE_DATA += IconFiles
icon/ios folder contains both Icon-*.png and Default-*.png files
It
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
14 matches
Mail list logo
