On Wednesday, 22 January 2014 at 08:25:05 UTC, Jordi Sayol wrote:
> El 22/01/14 02:06, Andrew Edwards ha escrit:
>> On 1/21/14, 6:02 PM, Jordi Sayol wrote:
>>> El 21/01/14 23:29, Brad Anderson ha escrit:
>>>>      #.###.~b#  ==> 2.065.b1  // beta
>>>>      #.###.~rc# ==> 2.065.rc1 // release candidate
>>>>      #.###.0   ==> 2.065.0   // initial release
>>>>      #.###.#   ==> 2.065.1   // hotfix
>>>
>>> On Debian, "2.065.rc1" is bigger than "2.065.0", so if "dmd_2.065.rc1-0_amd64.deb" is installed and you try to upgrade to "dmd_2.065.0-0_amd64.deb", system will answer something like "You have installed a newer version".
>>>
>>> No problem if these deb packages are for internal use and test, but not for a public download.
>>>
>>> $ dpkg --compare-versions "2.065.0" gt "2.065.rc1" && echo "Bigger" || echo "Not bigger"
>>>
>> 
>> Apparently the same problem exists on FreeBSD. The first solution that comes to mind is to prefix the qualifiers for betas and release candidates with a tilde. As such:
>> 
>>     2.065~b1
>>     2.065~rc1
>> 
>> or:
>> 
>>     2.065.~b1
>>     2.065.~rc1
>> 
>> This solution works on both Ubuntu and FreeBSD but I'm not sure it is the right one. Suggestions are welcomed.
>
> I prefer:
>
> 2.65~b1
> 2.65~rc1
>
> because "2.65.0" and "2.65" are bigger than "2.65~rc1", regardless if "qualifier" number is present or not in final release version.
>
> I think that, as much as possible, we should use exactly the same version string for all installers, zip, deb, rpm, dmg, etc.
> So if there is no problem on OSX, Windows, etc. I propose this versioning scheme:
>
> #.#~b#  ==> 2.65~b1  // beta
> #.#~rc# ==> 2.65~rc1 // release candidate
> #.#.#   ==> 2.65.0   // initial release
> #.#.#   ==> 2.65.1   // hotfix

I do not like the tilda scheme above. Because it does not conform to the major.minor.micro-qualifier scheme.

Before I propose another scheme, let me list some assumptions:

1) We will never have more than 3 release candidates.
2) Same goes for betas. You rarely see more than two beta releases for certain upcoming release of a product.

Therefore I propose the following (if it is "compatible" with FreeBSD and Debian) simple solution. We simply move beta and rc into the "qualifier".

So, we have:
2.065.0 (release)
2.065.0-rc2 (release candidate)
2.065.0-b1 (beta one)

This makes more sense IMHO.

Kind regards

El 26/01/14 16:23, Dejan Lekic ha escrit:
> On Wednesday, 22 January 2014 at 08:25:05 UTC, Jordi Sayol wrote:
>> El 22/01/14 02:06, Andrew Edwards ha escrit:
>>> On 1/21/14, 6:02 PM, Jordi Sayol wrote:
>>>> El 21/01/14 23:29, Brad Anderson ha escrit:
>>>>>      #.###.~b#  ==> 2.065.b1  // beta
>>>>>      #.###.~rc# ==> 2.065.rc1 // release candidate
>>>>>      #.###.0   ==> 2.065.0   // initial release
>>>>>      #.###.#   ==> 2.065.1   // hotfix
>>>>
>>>> On Debian, "2.065.rc1" is bigger than "2.065.0", so if "dmd_2.065.rc1-0_amd64.deb" is installed and you try to upgrade to "dmd_2.065.0-0_amd64.deb", system will answer something like "You have installed a newer version".
>>>>
>>>> No problem if these deb packages are for internal use and test, but not for a public download.
>>>>
>>>> $ dpkg --compare-versions "2.065.0" gt "2.065.rc1" && echo "Bigger" || echo "Not bigger"
>>>>
>>>
>>> Apparently the same problem exists on FreeBSD. The first solution that comes to mind is to prefix the qualifiers for betas and release candidates with a tilde. As such:
>>>
>>>     2.065~b1
>>>     2.065~rc1
>>>
>>> or:
>>>
>>>     2.065.~b1
>>>     2.065.~rc1
>>>
>>> This solution works on both Ubuntu and FreeBSD but I'm not sure it is the right one. Suggestions are welcomed.
>>
>> I prefer:
>>
>> 2.65~b1
>> 2.65~rc1
>>
>> because "2.65.0" and "2.65" are bigger than "2.65~rc1", regardless if "qualifier" number is present or not in final release version.
>>
>> I think that, as much as possible, we should use exactly the same version string for all installers, zip, deb, rpm, dmg, etc.
>> So if there is no problem on OSX, Windows, etc. I propose this versioning scheme:
>>
>> #.#~b#  ==> 2.65~b1  // beta
>> #.#~rc# ==> 2.65~rc1 // release candidate
>> #.#.#   ==> 2.65.0   // initial release
>> #.#.#   ==> 2.65.1   // hotfix
> 
> I do not like the tilda scheme above. Because it does not conform to the major.minor.micro-qualifier scheme.
> 
> Before I propose another scheme, let me list some assumptions:
> 
> 1) We will never have more than 3 release candidates.
> 2) Same goes for betas. You rarely see more than two beta releases for certain upcoming release of a product.
> 
> Therefore I propose the following (if it is "compatible" with FreeBSD and Debian) simple solution. We simply move beta and rc into the "qualifier".
> 
> So, we have:
> 2.065.0 (release)
> 2.065.0-rc2 (release candidate)
> 2.065.0-b1 (beta one)
> 
> This makes more sense IMHO.
> 


This scheme was already proposed by Leandro Lucarella, and I like it. http://forum.dlang.org/thread/lbmru9$290b$1@digitalmars.com#post-20140122001903.GE23332:40llucax.com.ar It only differs by leading zero on minor number, which can be cleanly removed.

Anyway, tilde is still mandatory on Debian packages due to upgrade reasons, so we can apply the Leandro's solution too: s/-/~/

Regards,
-- 
Jordi Sayol

On 1/26/14, 11:19 AM, Jordi Sayol wrote:
> El 26/01/14 16:23, Dejan Lekic ha escrit:
>> On Wednesday, 22 January 2014 at 08:25:05 UTC, Jordi Sayol wrote:
>>> El 22/01/14 02:06, Andrew Edwards ha escrit:
>>>> On 1/21/14, 6:02 PM, Jordi Sayol wrote:
>>>>> El 21/01/14 23:29, Brad Anderson ha escrit:
>>>>>>       #.###.~b#  ==> 2.065.b1  // beta
>>>>>>       #.###.~rc# ==> 2.065.rc1 // release candidate
>>>>>>       #.###.0   ==> 2.065.0   // initial release
>>>>>>       #.###.#   ==> 2.065.1   // hotfix
>>>>>
>>>>> On Debian, "2.065.rc1" is bigger than "2.065.0", so if "dmd_2.065.rc1-0_amd64.deb" is installed and you try to upgrade to "dmd_2.065.0-0_amd64.deb", system will answer something like "You have installed a newer version".
>>>>>
>>>>> No problem if these deb packages are for internal use and test, but not for a public download.
>>>>>
>>>>> $ dpkg --compare-versions "2.065.0" gt "2.065.rc1" && echo "Bigger" || echo "Not bigger"
>>>>>
>>>>
>>>> Apparently the same problem exists on FreeBSD. The first solution that comes to mind is to prefix the qualifiers for betas and release candidates with a tilde. As such:
>>>>
>>>>      2.065~b1
>>>>      2.065~rc1
>>>>
>>>> or:
>>>>
>>>>      2.065.~b1
>>>>      2.065.~rc1
>>>>
>>>> This solution works on both Ubuntu and FreeBSD but I'm not sure it is the right one. Suggestions are welcomed.
>>>
>>> I prefer:
>>>
>>> 2.65~b1
>>> 2.65~rc1
>>>
>>> because "2.65.0" and "2.65" are bigger than "2.65~rc1", regardless if "qualifier" number is present or not in final release version.
>>>
>>> I think that, as much as possible, we should use exactly the same version string for all installers, zip, deb, rpm, dmg, etc.
>>> So if there is no problem on OSX, Windows, etc. I propose this versioning scheme:
>>>
>>> #.#~b#  ==> 2.65~b1  // beta
>>> #.#~rc# ==> 2.65~rc1 // release candidate
>>> #.#.#   ==> 2.65.0   // initial release
>>> #.#.#   ==> 2.65.1   // hotfix
>>
>> I do not like the tilda scheme above. Because it does not conform to the major.minor.micro-qualifier scheme.
>>
>> Before I propose another scheme, let me list some assumptions:
>>
>> 1) We will never have more than 3 release candidates.
>> 2) Same goes for betas. You rarely see more than two beta releases for certain upcoming release of a product.
>>
>> Therefore I propose the following (if it is "compatible" with FreeBSD and Debian) simple solution. We simply move beta and rc into the "qualifier".
>>
>> So, we have:
>> 2.065.0 (release)
>> 2.065.0-rc2 (release candidate)
>> 2.065.0-b1 (beta one)
>>
>> This makes more sense IMHO.
>>
>
>
> This scheme was already proposed by Leandro Lucarella, and I like it.
> http://forum.dlang.org/thread/lbmru9$290b$1@digitalmars.com#post-20140122001903.GE23332:40llucax.com.ar
> It only differs by leading zero on minor number, which can be cleanly removed.
>
> Anyway, tilde is still mandatory on Debian packages due to upgrade reasons, so we can apply the Leandro's solution too:
> s/-/~/
>
> Regards,
>

Jordi, I need you to explain this. You wrote the scripts for the pkg installers right? What happens when you pass a version number containing a "-" to dmd_rpm.sh? I'll tell you:

	Building for target platforms: i386
	Building for target i386
	error: line 2: Illegal character '-' in: Version: 2.065.0-b2

I initially changed the naming convention because of errors like these cropping up all over your scripts. Change it to '~' and it craps out on another one of your scrips for a different package. Multiple other

My question is, what is the proper version scheme that fits all the systems that you are trying to make these packages for? This one obviously does not work for at lease one of them.

El 26/01/14 21:59, Andrew Edwards ha escrit:
> On 1/26/14, 11:19 AM, Jordi Sayol wrote:
>> El 26/01/14 16:23, Dejan Lekic ha escrit:
>>> On Wednesday, 22 January 2014 at 08:25:05 UTC, Jordi Sayol wrote:
>>>> El 22/01/14 02:06, Andrew Edwards ha escrit:
>>>>> On 1/21/14, 6:02 PM, Jordi Sayol wrote:
>>>>>> El 21/01/14 23:29, Brad Anderson ha escrit:
>>>>>>>       #.###.~b#  ==> 2.065.b1  // beta
>>>>>>>       #.###.~rc# ==> 2.065.rc1 // release candidate
>>>>>>>       #.###.0   ==> 2.065.0   // initial release
>>>>>>>       #.###.#   ==> 2.065.1   // hotfix
>>>>>>
>>>>>> On Debian, "2.065.rc1" is bigger than "2.065.0", so if "dmd_2.065.rc1-0_amd64.deb" is installed and you try to upgrade to "dmd_2.065.0-0_amd64.deb", system will answer something like "You have installed a newer version".
>>>>>>
>>>>>> No problem if these deb packages are for internal use and test, but not for a public download.
>>>>>>
>>>>>> $ dpkg --compare-versions "2.065.0" gt "2.065.rc1" && echo "Bigger" || echo "Not bigger"
>>>>>>
>>>>>
>>>>> Apparently the same problem exists on FreeBSD. The first solution that comes to mind is to prefix the qualifiers for betas and release candidates with a tilde. As such:
>>>>>
>>>>>      2.065~b1
>>>>>      2.065~rc1
>>>>>
>>>>> or:
>>>>>
>>>>>      2.065.~b1
>>>>>      2.065.~rc1
>>>>>
>>>>> This solution works on both Ubuntu and FreeBSD but I'm not sure it is the right one. Suggestions are welcomed.
>>>>
>>>> I prefer:
>>>>
>>>> 2.65~b1
>>>> 2.65~rc1
>>>>
>>>> because "2.65.0" and "2.65" are bigger than "2.65~rc1", regardless if "qualifier" number is present or not in final release version.
>>>>
>>>> I think that, as much as possible, we should use exactly the same version string for all installers, zip, deb, rpm, dmg, etc.
>>>> So if there is no problem on OSX, Windows, etc. I propose this versioning scheme:
>>>>
>>>> #.#~b#  ==> 2.65~b1  // beta
>>>> #.#~rc# ==> 2.65~rc1 // release candidate
>>>> #.#.#   ==> 2.65.0   // initial release
>>>> #.#.#   ==> 2.65.1   // hotfix
>>>
>>> I do not like the tilda scheme above. Because it does not conform to the major.minor.micro-qualifier scheme.
>>>
>>> Before I propose another scheme, let me list some assumptions:
>>>
>>> 1) We will never have more than 3 release candidates.
>>> 2) Same goes for betas. You rarely see more than two beta releases for certain upcoming release of a product.
>>>
>>> Therefore I propose the following (if it is "compatible" with FreeBSD and Debian) simple solution. We simply move beta and rc into the "qualifier".
>>>
>>> So, we have:
>>> 2.065.0 (release)
>>> 2.065.0-rc2 (release candidate)
>>> 2.065.0-b1 (beta one)
>>>
>>> This makes more sense IMHO.
>>>
>>
>>
>> This scheme was already proposed by Leandro Lucarella, and I like it. http://forum.dlang.org/thread/lbmru9$290b$1@digitalmars.com#post-20140122001903.GE23332:40llucax.com.ar It only differs by leading zero on minor number, which can be cleanly removed.
>>
>> Anyway, tilde is still mandatory on Debian packages due to upgrade reasons, so we can apply the Leandro's solution too: s/-/~/
>>
>> Regards,
>>
> 
> Jordi, I need you to explain this. You wrote the scripts for the pkg installers right? What happens when you pass a version number containing a "-" to dmd_rpm.sh? I'll tell you:
> 
>     Building for target platforms: i386
>     Building for target i386
>     error: line 2: Illegal character '-' in: Version: 2.065.0-b2
> 
> I initially changed the naming convention because of errors like these cropping up all over your scripts. Change it to '~' and it craps out on another one of your scrips for a different package. Multiple other
> 
> My question is, what is the proper version scheme that fits all the systems that you are trying to make these packages for? This one obviously does not work for at lease one of them.

Andrew, the current deb/rpm building script version scheme is:

^[0-9]"."[0-9][0-9][0-9]$
or
^[0-9]"."[0-9][0-9][0-9]"."[0-9]+$


I'm waiting to know the final new dmd versioning scheme. As soon as it is stablished, I'll modify these scripts to allow them.

Of course if the new scheme contains "*-b?" or "*-rc?", "-" will be replaced by "~", for a correct package upgrade on Debian.

I don't know if this happens on rpm systems too. I'll investigate.

Regards,
-- 
Jordi Sayol

On 1/26/14, 3:59 PM, Andrew Edwards wrote:
>
> Jordi, I need you to explain this. You wrote the scripts for the pkg
> installers right? What happens when you pass a version number containing
> a "-" to dmd_rpm.sh? I'll tell you:
>
>      Building for target platforms: i386
>      Building for target i386
>      error: line 2: Illegal character '-' in: Version: 2.065.0-b2
>
> I initially changed the naming convention because of errors like these
> cropping up all over your scripts. Change it to '~' and it craps out on
> another one of your scrips for a different package. Multiple other
>
> My question is, what is the proper version scheme that fits all the
> systems that you are trying to make these packages for? This one
> obviously does not work for at lease one of them.
>

It sent before finishing my thoughts. Anyway, the scheme you are lobbying for is the one being used. Just gotta figure out what to do about rpm for Suse and Fedora.

On 1/26/14, 4:20 PM, Jordi Sayol wrote:
> El 26/01/14 21:59, Andrew Edwards ha escrit:
>>
>> Jordi, I need you to explain this. You wrote the scripts for the pkg installers right? What happens when you pass a version number containing a "-" to dmd_rpm.sh? I'll tell you:
>>
>>      Building for target platforms: i386
>>      Building for target i386
>>      error: line 2: Illegal character '-' in: Version: 2.065.0-b2
>>
>> I initially changed the naming convention because of errors like these cropping up all over your scripts. Change it to '~' and it craps out on another one of your scrips for a different package. Multiple other
>>
>> My question is, what is the proper version scheme that fits all the systems that you are trying to make these packages for? This one obviously does not work for at lease one of them.
>
> Andrew, the current deb/rpm building script version scheme is:
>
> ^[0-9]"."[0-9][0-9][0-9]$
> or
> ^[0-9]"."[0-9][0-9][0-9]"."[0-9]+$
>

I've modified the version scheme so the script does not have a problem identifying the zip. It simply craps the bed when it reaches dmd_rpm.sh.

El 26/01/14 22:37, Andrew Edwards ha escrit:
> On 1/26/14, 4:20 PM, Jordi Sayol wrote:
>> El 26/01/14 21:59, Andrew Edwards ha escrit:
>>>
>>> Jordi, I need you to explain this. You wrote the scripts for the pkg installers right? What happens when you pass a version number containing a "-" to dmd_rpm.sh? I'll tell you:
>>>
>>>      Building for target platforms: i386
>>>      Building for target i386
>>>      error: line 2: Illegal character '-' in: Version: 2.065.0-b2
>>>
>>> I initially changed the naming convention because of errors like these cropping up all over your scripts. Change it to '~' and it craps out on another one of your scrips for a different package. Multiple other
>>>
>>> My question is, what is the proper version scheme that fits all the systems that you are trying to make these packages for? This one obviously does not work for at lease one of them.
>>
>> Andrew, the current deb/rpm building script version scheme is:
>>
>> ^[0-9]"."[0-9][0-9][0-9]$
>> or
>> ^[0-9]"."[0-9][0-9][0-9]"."[0-9]+$
>>
> 
> I've modified the version scheme so the script does not have a problem identifying the zip. It simply craps the bed when it reaches dmd_rpm.sh.
> 


[...]
error: line 2: Illegal char '-' in: Version: 2.065.0-b2
-----

rpm packages do not allows "-" on version.

I've pull-requested deb/rpm scripts to fix new dmd versioning scheme. Dash "-" is replaced by tilde "~" on deb/rpm packages version, and so on packages name.
https://github.com/D-Programming-Language/installer/pull/47

-- 
Jordi Sayol

On Wednesday, 22 January 2014 at 13:37:07 UTC, Sönke Ludwig wrote:
> I'm getting deprecation warnings inside std.datetime to use "any" instead of "canFind".
>
> Also DMD now warns about using FP operators, such as <>=, for detecting NaN's. What's the rationale for this? One issue with this is that isNaN cannot be used for CTFE.


To detect NaNs, you just need to change x <>= x into x == x.

Actually almost all uses of isNaN in std.math are unnecessarily slow, std.math.isNaN doesn't trigger signalling NaNs but almost every function in std.math _should_ trigger signalling NaNs, so should use the much faster

bool isNaN(real x) { return x != x; }

Am 27.01.2014 10:37, schrieb Don:
> On Wednesday, 22 January 2014 at 13:37:07 UTC, Sönke Ludwig wrote:
>> I'm getting deprecation warnings inside std.datetime to use "any"
>> instead of "canFind".
>>
>> Also DMD now warns about using FP operators, such as <>=, for
>> detecting NaN's. What's the rationale for this? One issue with this is
>> that isNaN cannot be used for CTFE.
>
>
> To detect NaNs, you just need to change x <>= x into x == x.

I've used x <>= 0 so far to avoid having the "x" expression appear twice, not really a problem to change it, but I was a bit surprised about the warning. So if I understand it correctly (someone mentioned it somewhere on the .D group), all FP specific comparison operators are going to get deprecated?

Am 22.01.2014 14:37, schrieb Sönke Ludwig:
> There is also a build issue that sometimes occurred at the same place in
> 2.064 in the form of template instantiation failures and now produces
> linker errors: https://github.com/rejectedsoftware/vibe.d/issues/458
>

https://d.puremagic.com/issues/show_bug.cgi?id=12010

Another error with undefined symbols is still being reduced by Dustmite and will likely take another two days (unfortunately it involves a fairly large code base with multiple separate static libraries).