Re: [Development] Adding support for version number comparisons
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 should be supported? Please look at the version comparison rules that for example dpkg uses. Especially tilde. [1] And special strings (alpha, rc, ..) should not be treated special. /Sune [1] https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Ios: Launch image is always black
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 works fine with the icons but not with the launch image.
Searching the web I found BUG-31431 and the resolution that consists of
forcing a blank default-5...@2.png in the default_post.prf script. I
understand reading the comment of the bug report that if we want to have a
custom image we need to use a custom plist and define a different name for
the image from the default one.
Is my undertansding ok ? Is there another way to have a custom image as I
don't have currently a custom plist file? Any plan of modifying this ?
Regards,
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
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 proposed. > > > > 3. Are there any other versioning semantics that should be > > supported? > > Please look at the version comparison rules that for example dpkg uses. > Especially tilde. [1] > > And special strings (alpha, rc, ..) should not be treated special. How do you make 5.3.0-rc1 compare less than 5.3.0? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
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 >>> suffix, >>> many different methods are being proposed. >>> >>> 3. Are there any other versioning semantics that should be >>> supported? >> >> Please look at the version comparison rules that for example dpkg uses. >> Especially tilde. [1] >> >> And special strings (alpha, rc, ..) should not be treated special. > > How do you make 5.3.0-rc1 compare less than 5.3.0? > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Easy. Empty suffix always compares higher. 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...). -- Jake Petroules - jake.petroules at petroules.com Chief Technology Officer - Petroules Corporation ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
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? (OpenSSL) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
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...). > > So how do you mean 1.0.0b compare greater than 1.0.0? (OpenSSL) > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development OK, if suffix begins with '-', compare < empty, else, compare > empty. -- Jake Petroules - jake.petroules at petroules.com Chief Technology Officer - Petroules Corporation ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
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, May 10, 2014 at 1:18 PM, Jake Petroules < jake.petrou...@petroules.com> wrote: > 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...). > > > > So how do you mean 1.0.0b compare greater than 1.0.0? (OpenSSL) > > > > -- > > Thiago Macieira - thiago.macieira (AT) intel.com > > Software Architect - Intel Open Source Technology Center > > > > ___ > > Development mailing list > > Development@qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > OK, if suffix begins with '-', compare < empty, else, compare > empty. > -- > Jake Petroules - jake.petroules at petroules.com > Chief Technology Officer - Petroules Corporation > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
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 Berlin for Qt Developer Days 2014! Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel. UK +44-1738-450410, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
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 reasonably well for all of them at the same time. At the absolute least we should have some means to use a custom suffix comparison (compare() overload that takes a function as a parameter?). -- Jake Petroules - jake.petroules at petroules.com Chief Technology Officer - Petroules Corporation On 2014-05-10, at 03:20 PM, Keith Gardner wrote: > 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, May 10, 2014 at 1:18 PM, Jake Petroules > wrote: > 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...). > > > > So how do you mean 1.0.0b compare greater than 1.0.0? (OpenSSL) > > > > -- > > Thiago Macieira - thiago.macieira (AT) intel.com > > Software Architect - Intel Open Source Technology Center > > > > ___ > > Development mailing list > > Development@qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > OK, if suffix begins with '-', compare < empty, else, compare > empty. > -- > Jake Petroules - jake.petroules at petroules.com > Chief Technology Officer - Petroules Corporation > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
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 least, > within the suffix part) that it's nearly impossible to do something that > works reasonably well for all of them at the same time. > > At the absolute least we should have some means to use a custom suffix > comparison (compare() overload that takes a function as a parameter?). > Correct me if I am wrong but it sounds like there needs to be some additional information to perform the compare. It looks like the suffix needs to be labeled as pre-release or release for each version. Instead of putting that into the compare, it could be a member variable for the QVersion. This would allow for "1.0.0b2" to compare properly with "1.0.0beta" without providing extra flags and the label will follow the instance of QVersion. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
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
Re: [Development] Adding support for version number comparisons
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 requirements from the original post: >- 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 installations and updates. >- QMake support for version number comparisons. Four of the five of those require parsing input that other people create. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
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 part) that it's nearly impossible to do something that works > reasonably well for all of them at the same time. > > At the absolute least we should have some means to use a custom suffix > comparison (compare() overload that takes a function as a parameter?). If you need that, I'd say you should setSuffix(QString()), compare() and, if it compares equally, implement your own custom comparison. Anyway, given that this is going to be complex, I propose we make up our own list and *document* it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding support for version number comparisons
> > 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, "1.0.0", but we should define what the pre-release and release ones look like. Below are my thoughts about some characteristics for the two difficult types. Pre-release Suffixes: 1. Usually has some keywords identify it: alpha, beta, gamma, and rc. 2. These keywords can be anywhere in the suffix and can potentially be abbreviated to a single character [1]. 3. These keywords can have an optional numerical index. 4. Some projects use repository identifiers: svn commit number, git SHA, build ID. 5. As seen in this email chain, there are many different types of delimiters (- ~ .). Release Suffixes: 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). 4. Repository identifiers also are used, i.e. XCode's clang copy. 5. Multiple types of delimiters are used as well. What am I missing in these lists and how should we go about supporting them? I am not proposing that we support every version number policy out there but what is the most common cases so that we can cover the majority. [1] http://en.wikipedia.org/wiki/Software_versioning#Pre-release_versions Thanks, Keith ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
