Re: dmd 2.065 beta 1 #2
Andrew Edwards wrote: > 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. This naming scheme would not be accepted by Fedora/openSuSE/Mageia people. That is one of the reasons why I talked about the major.minor.micro- qualifier scheme... No tildas there are in use. -- http://dejan.lekic.org
Re: dmd 2.065 beta 1 #2
On 01/27/2014 03:10 AM, Jordi Sayol wrote: [...] 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 I get: rpm packages do not allows "~" on version. As I wrote earlier we're stuck with RPM 4.8.1 which doesn't allow the use of tilde. In fact Fedoras package guidelines explicitly discourage using "~" https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Pre-Release_packages and suggests to use the 'Release' field. Currently we always set this to 0 (https://github.com/D-Programming-Language/installer/blob/4df7d4339062a348739c5c8e884bdf09bdad4778/linux/dmd_rpm.sh#L287), but we're supposed to enumerate the prerelease versions with 0.1.b1, 0.2.b2, 0.3.b3, 0.4.rc1, 0.5.rc2. For a final version this will become 1 andOnce a final build it will start with 1 and potential rebuilds get a 2, 3. The i386 fedora rpm names would looks this. dmd.2.065.0-0.1.b1.fedora.i386.rpm //<- Beta1 dmd.2.065.0-0.2.b2.fedora.i386.rpm //<- Beta2 dmd.2.065.0-0.3.b3.fedora.i386.rpm //<- Beta3 dmd.2.065.0-0.4.rc1.fedora.i386.rpm //<- RC1 dmd.2.065.0-0.5.rc2.fedora.i386.rpm //<- RC2 dmd.2.065.0-1.fedora.i386.rpm //<- final release dmd.2.065.0-2.fedora.i386.rpm //<- fixup of the "final" release The important part is, that the beta stuff stay out of the version number. Only the 'Release' field is allowed to have letters. I'm a bit unsure how that would continue with 2.065.1. dmd.2.065.1-0.1.b1.fedora.i386.rpm dmd.2.065.1-0.2.rc1.fedora.i386.rpm dmd.2.065.1-1.fedora.i386.rpm Would that work for OpenSuse and .deb too? -Martin
Re: dmd 2.065 beta 1 #2
On 01/27/2014 03:10 AM, Jordi Sayol wrote: [...] 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 Tilde doesn't work for rpm (I'm stuck with a slightly older rpmbuild 4.8.1). https://github.com/D-Programming-Language/installer/commit/c74853d8b6ea243ee8889f9790f7c3d5099abe5d#commitcomment-5264134 The Fedora manual has a detailed description on how to handle this. https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Version_Tag
Re: dmd 2.065 beta 1 #2
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).
Re: dmd 2.065 beta 1 #2
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?
Re: dmd 2.065 beta 1 #2
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; }
Re: dmd 2.065 beta 1 #2
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
Re: dmd 2.065 beta 1 #2
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.
Re: dmd 2.065 beta 1 #2
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.
Re: dmd 2.065 beta 1 #2
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
Re: dmd 2.065 beta 1 #2
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.
Re: dmd 2.065 beta 1 #2
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
Re: dmd 2.065 beta 1 #2
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
Re: dmd 2.065 beta 1 #2
"Martin Nowak" wrote in message news:jcszzsgkwldowcmwz...@forum.dlang.org... Mmh, we could simply upload the intermediate zip files for each platform, that fall out of create_dmd_release before they are combined. Any ETA on this? I'd like to provide a win32 version with dmd replaced by ddmd for people to test.
Re: dmd 2.065 beta 1 #2
On Friday, 24 January 2014 at 19:58:22 UTC, Andrew Edwards wrote: On 1/24/14, 10:04 AM, Dejan Lekic wrote: Could you please make a "2.065.b1" tag on the GitHub as well so we finally start using the release naming scheme you mentioned in the previous beta-release thread here on the NG? 2.065.b1 is not going to work for FreeBSD and Debian OSes. The tags will be in the form: 2.65.0-b1. Hope that doesn't mess with your scripts too much. I will not be uploading one for beta 1 since I will be building beta 2 tonight. I was eager to try the beta2 on my debian, but it seems things didn't turned out to work yesterday.
Re: dmd 2.065 beta 1 #2
On 1/24/14, 10:04 AM, Dejan Lekic wrote: Could you please make a "2.065.b1" tag on the GitHub as well so we finally start using the release naming scheme you mentioned in the previous beta-release thread here on the NG? 2.065.b1 is not going to work for FreeBSD and Debian OSes. The tags will be in the form: 2.65.0-b1. Hope that doesn't mess with your scripts too much. I will not be uploading one for beta 1 since I will be building beta 2 tonight.
Re: dmd 2.065 beta 1 #2
Could you please make a "2.065.b1" tag on the GitHub as well so we finally start using the release naming scheme you mentioned in the previous beta-release thread here on the NG?
Re: dmd 2.065 beta 1 #2
On 1/24/14, 9:17 AM, Martin Nowak wrote: On 01/23/2014 01:44 PM, Martin Nowak wrote: 1) The link for nsisunz.zip per readme.txt does not work. I wrote the author of the plugin. He no longer has posses this file. @Brad Anderson, maybe you or Walter still have a download laying around? Martin, there is no need. I included a link to where I found the copy I am using. What might need to be done is a copy stored on the server but my main point was that the readme file need to be updated.
Re: dmd 2.065 beta 1 #2
On 01/23/2014 01:44 PM, Martin Nowak wrote: 1) The link for nsisunz.zip per readme.txt does not work. I wrote the author of the plugin. He no longer has posses this file. @Brad Anderson, maybe you or Walter still have a download laying around?
Re: dmd 2.065 beta 1 #2
On 01/24/2014 12:24 AM, Brad Anderson wrote: The NSIS script already requires a bit of manual editing (basically just updating the version number). I think I can probably figure out a way to do away with that though (NSIS can pull definitions from a separate file and the NSIS command line supports specifying definitions). I'll experiment with these soon and see what I can do to allow it to be completely automated. Sounds great, my mid term goal is to integrate all the package/installer scripts with the vagrant setup and to build them using local dmd.zip folders.
Re: dmd 2.065 beta 1 #2
Am 23.01.2014 10:38, schrieb Walter Bright: On 1/22/2014 5:37 AM, Sönke Ludwig wrote: (...) 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 Did you try the -allinst flag? Tried it, but it didn't make a difference. I'm running Dustmite on it now, but that will take a while to complete. Finally, I'm getting some "recursive alias" errors that I managed to circumvent in previous releases. I'm going to run dustmite on these two and create bugzilla issues. Unfortunately, in case of the recursive alias error, Dustmite reduced to a case that fails for both, 2.065 and 2.064. Also, every little change from there either fixes the error or makes it appear again. This is obviously stabbing too deep in unspecified language territory. I gave up on it and am now in the process of completely rewriting the affected code.
Re: dmd 2.065 beta 1 #2
On Thursday, 23 January 2014 at 23:44:09 UTC, Jordi Sayol wrote: El 24/01/14 00:24, Brad Anderson ha escrit: On Thursday, 23 January 2014 at 13:29:31 UTC, Martin Nowak wrote: On Thursday, 23 January 2014 at 06:50:47 UTC, Brad Anderson wrote: This of course is relying on the zip file getting uploaded to downloads.dlang.org. You could use the digitalmars urls for betas, I suppose, since those don't end up on the download site anyway. The url template is just a bit further down in the file. Please no manual steps. Is it possible to do this in the nsi script? Well, presumably Andrew will get access to upload to the download site at some point soon and he's just use that instead of digitalmars's FTP and this won't be a problem. The NSIS script already requires a bit of manual editing (basically just updating the version number). I think I can probably figure out a way to do away with that though (NSIS can pull definitions from a separate file and the NSIS command line supports specifying definitions). I'll experiment with these soon and see what I can do to allow it to be completely automated. You can take a look on linux/win/installer.nsi that get version argument from linux/dmd_win.sh and therefore from command line. Ok, cool. I'll take a look there.
Re: dmd 2.065 beta 1 #2
On 1/23/14, 7:25 PM, vitaly_m wrote: On Tuesday, 21 January 2014 at 22:22:01 UTC, Andrew Edwards wrote: For a description of these packages, visit http://dlang.org/downloads.html. The link should be http://dlang.org/download.html (no 's' before .html) Thanks
Re: dmd 2.065 beta 1 #2
On Tuesday, 21 January 2014 at 22:22:01 UTC, Andrew Edwards wrote: For a description of these packages, visit http://dlang.org/downloads.html. The link should be http://dlang.org/download.html (no 's' before .html)
Re: dmd 2.065 beta 1 #2
On 01/22/2014 02:37 PM, Sönke Ludwig wrote: I'm getting deprecation warnings inside std.datetime to use "any" instead of "canFind". https://github.com/D-Programming-Language/phobos/pull/1876
Re: dmd 2.065 beta 1 #2
El 24/01/14 00:24, Brad Anderson ha escrit: > On Thursday, 23 January 2014 at 13:29:31 UTC, Martin Nowak wrote: >> On Thursday, 23 January 2014 at 06:50:47 UTC, Brad Anderson wrote: >>> This of course is relying on the zip file getting uploaded to >>> downloads.dlang.org. You could use the digitalmars urls for >>> betas, I suppose, since those don't end up on the download site >>> anyway. The url template is just a bit further down in the file. >> >> Please no manual steps. Is it possible to do this in the nsi script? > > Well, presumably Andrew will get access to upload to the download site at > some point soon and he's just use that instead of digitalmars's FTP and this > won't be a problem. > > The NSIS script already requires a bit of manual editing (basically just > updating the version number). I think I can probably figure out a way to do > away with that though (NSIS can pull definitions from a separate file and the > NSIS command line supports specifying definitions). I'll experiment with > these soon and see what I can do to allow it to be completely automated. > You can take a look on linux/win/installer.nsi that get version argument from linux/dmd_win.sh and therefore from command line. -- Jordi Sayol
Re: dmd 2.065 beta 1 #2
On Thursday, 23 January 2014 at 13:29:31 UTC, Martin Nowak wrote: On Thursday, 23 January 2014 at 06:50:47 UTC, Brad Anderson wrote: This of course is relying on the zip file getting uploaded to downloads.dlang.org. You could use the digitalmars urls for betas, I suppose, since those don't end up on the download site anyway. The url template is just a bit further down in the file. Please no manual steps. Is it possible to do this in the nsi script? Well, presumably Andrew will get access to upload to the download site at some point soon and he's just use that instead of digitalmars's FTP and this won't be a problem. The NSIS script already requires a bit of manual editing (basically just updating the version number). I think I can probably figure out a way to do away with that though (NSIS can pull definitions from a separate file and the NSIS command line supports specifying definitions). I'll experiment with these soon and see what I can do to allow it to be completely automated.
Re: dmd 2.065 beta 1 #2
On Wednesday, 22 January 2014 at 03:43:51 UTC, Andrew Edwards wrote: On 1/21/14, 5:29 PM, Brad Anderson wrote: On Tuesday, 21 January 2014 at 22:22:01 UTC, Andrew Edwards wrote: Note: An installer is not yet prepared for Windows. Let me know if you need any guidance on getting the Windows installer working. Please use the one in windows/dinstaller.nsi (I need to get some free time to unify that with Jordi's windows installer in the linux folder). 1) The link for nsisunz.zip per readme.txt does not work. Very common with NSIS, unfortunately. It's kind of a ghetto.
Re: dmd 2.065 beta 1 #2
On 01/23/2014 01:33 PM, Dejan Lekic wrote: It would be nice, IMHO, to have release information in the same fashion VisualD does it. Check: https://github.com/D-Programming-Language/visuald/releases . Notice that each release has changelog. -Very nice and professional I think. Yeah, maybe we can do something useful with the github release page. We do already have a changelog though, http://dlang.org/changelog.html.
Re: dmd 2.065 beta 1 #2
Jacob Carlborg, el 23 de January a las 11:39 me escribiste: > On 2014-01-23 10:15, Mathias LANG wrote: > > >As Jacob already said, we will either need to go back to a major of 0, > >or improve our major number almost everytime there is a release. > > Ruby has just adopted the semantic versioning scheme[1] . They added > a fourth digit. The first digit will be the version of the language, > the remaining three digits will work as the regular semantic > versioning scheme. > > [1] > https://www.ruby-lang.org/en/news/2013/12/21/semantic-versioning-after-2-1-0/ Works for me. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Software is like sex: it's better when it's free. -- Linus Torvalds
Re: dmd 2.065 beta 1 #2
"Martin Nowak" wrote in message news:jcszzsgkwldowcmwz...@forum.dlang.org... Mmh, we could simply upload the intermediate zip files for each platform, that fall out of create_dmd_release before they are combined. Sounds good.
Re: dmd 2.065 beta 1 #2
On Thursday, 23 January 2014 at 06:50:47 UTC, Brad Anderson wrote: This of course is relying on the zip file getting uploaded to downloads.dlang.org. You could use the digitalmars urls for betas, I suppose, since those don't end up on the download site anyway. The url template is just a bit further down in the file. Please no manual steps. Is it possible to do this in the nsi script?
Re: dmd 2.065 beta 1 #2
On Wednesday, 22 January 2014 at 03:46:55 UTC, Daniel Murphy wrote: While you're at it, can we get per-platform zips? Just take the normal zip and delete all but one platform. Mmh, we could simply upload the intermediate zip files for each platform, that fall out of create_dmd_release before they are combined.
Re: dmd 2.065 beta 1 #2
On Wednesday, 22 January 2014 at 03:43:51 UTC, Andrew Edwards wrote: 1) The link for nsisunz.zip per readme.txt does not work. I wrote the author of the plugin.
Re: dmd 2.065 beta 1 #2
On Tuesday, 21 January 2014 at 22:22:01 UTC, Andrew Edwards wrote: Due to building an packaging requirements and a need to address the concerns of the community, I changed the naming convention for this and all future releases. The following is our new naming convention: major.minor.qualifier Examples follow: #.###.b# ==> 2.065.b1 // beta #.###.rc# ==> 2.065.rc1 // release candidate #.###.0 ==> 2.065.0 // initial release #.###.# ==> 2.065.1 // hotfix Consequently, the name for the previously announced beta has changed. Additionally, installers were prepared and made available. They are as follows: ftp://ftp.digitalmars.com/dmd.2.065.b1.zip ftp://ftp.digitalmars.com/dmd.2.065.b1.dmg ftp://ftp.digitalmars.com/dmd_2.065.b1-0_i386.deb ftp://ftp.digitalmars.com/dmd_2.065.b1-0_amd64.deb ftp://ftp.digitalmars.com/dmd-2.065.b1-0.fedora.i386.rpm ftp://ftp.digitalmars.com/dmd-2.065.b1-0.fedora.x86_64.rpm ftp://ftp.digitalmars.com/dmd-2.065.b1-0.openSUSE.i386.rpm ftp://ftp.digitalmars.com/dmd-2.065.b1-0.openSUSE.x86_64.rpm For a description of these packages, visit http://dlang.org/downloads.html. Note: An installer is not yet prepared for Windows. Regards, Andrew It would be nice, IMHO, to have release information in the same fashion VisualD does it. Check: https://github.com/D-Programming-Language/visuald/releases . Notice that each release has changelog. -Very nice and professional I think.
Re: dmd 2.065 beta 1 #2
On 2014-01-23 10:15, Mathias LANG wrote: As Jacob already said, we will either need to go back to a major of 0, or improve our major number almost everytime there is a release. Ruby has just adopted the semantic versioning scheme[1] . They added a fourth digit. The first digit will be the version of the language, the remaining three digits will work as the regular semantic versioning scheme. [1] https://www.ruby-lang.org/en/news/2013/12/21/semantic-versioning-after-2-1-0/ -- /Jacob Carlborg
Re: dmd 2.065 beta 1 #2
On 1/22/2014 5:37 AM, 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. 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 Did you try the -allinst flag? Finally, I'm getting some "recursive alias" errors that I managed to circumvent in previous releases. I'm going to run dustmite on these two and create bugzilla issues.
Re: dmd 2.065 beta 1 #2
On Wednesday, 22 January 2014 at 13:09:19 UTC, Leandro Lucarella wrote: There is a fairly popular de-facto standard for versioning: semver. Yes, it is incompatible with Debian (and I guess FreeBSD) but you can make it compatible by just changing one character ("-" -> "~"). Since apparently a version naming scheme is needed, does anyone have a good reason NOT to use a standard that's easily adaptable to several popular distributions? As Jacob already said, we will either need to go back to a major of 0, or improve our major number almost everytime there is a release.
Re: dmd 2.065 beta 1 #2
On Wednesday, 22 January 2014 at 03:34:40 UTC, Andrew Edwards wrote: On 1/21/14, 5:22 PM, Andrew Edwards wrote: Note: An installer is not yet prepared for Windows. It is now added: ftp://ftp.digitalmars.com/dmd-2.065.b1.exe This of course is relying on the zip file getting uploaded to downloads.dlang.org. You could use the digitalmars urls for betas, I suppose, since those don't end up on the download site anyway. The url template is just a bit further down in the file.
Re: dmd 2.065 beta 1 #2
On 2014-01-21 23:22, Andrew Edwards wrote: Due to building an packaging requirements and a need to address the concerns of the community, I changed the naming convention for this and all future releases. I'm getting some regressions when compiling Tango. I filed one bug report but having trouble creating a reduced test case for the other one. The error I get is: Regex.d(2524): Error: associative array key type TagIndex does not have 'const int opCmp(ref const TagIndex)' member function Regex.d(3676): Error: template instance tango.text.Regex.TDFA!dchar error instantiating Regex.d(4420):instantiated from here: RegExpT!char Regex.d(4407): Error: tdfa_t.Command is used as a type Regex.d(4420): Error: template instance tango.text.Regex.RegExpT!char error instantiating TagIndex looks like this: struct TagIndex { uint tag, index; } And it's used in an associative array: uint[TagIndex] registers; -- /Jacob Carlborg
Re: dmd 2.065 beta 1 #2
On 2014-01-22 13:16, Andrew Edwards wrote: That might be the case. I'm following the instructions here: https://github.com/D-Programming-Language/installer/tree/master/osx Last update was over 9 months ago. https://github.com/D-Programming-Language/installer/pull/44 -- /Jacob Carlborg
Re: dmd 2.065 beta 1 #2
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. 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 Finally, I'm getting some "recursive alias" errors that I managed to circumvent in previous releases. I'm going to run dustmite on these two and create bugzilla issues.
Re: dmd 2.065 beta 1 #2
On 2014-01-22 13:16, Andrew Edwards wrote: That might be the case. I'm following the instructions here: https://github.com/D-Programming-Language/installer/tree/master/osx Last update was over 9 months ago. I just noticed an error in the Makefile. I'll create a pull request. -- /Jacob Carlborg
Re: dmd 2.065 beta 1 #2
Andrew Edwards, el 21 de January a las 20:06 me escribiste: > 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. There is a fairly popular de-facto standard for versioning: semver. Yes, it is incompatible with Debian (and I guess FreeBSD) but you can make it compatible by just changing one character ("-" -> "~"). Since apparently a version naming scheme is needed, does anyone have a good reason NOT to use a standard that's easily adaptable to several popular distributions? -- Leandro Lucarella (AKA luca) http://llucax.com.ar/
Re: dmd 2.065 beta 1 #2
On 1/22/14, 3:38 AM, Jacob Carlborg wrote: On 2014-01-21 23:22, Andrew Edwards wrote: ftp://ftp.digitalmars.com/dmd.2.065.b1.dmg The installer is old. The text contains links to D1. The content seem to be correct though. How are you building the installer. That might be the case. I'm following the instructions here: https://github.com/D-Programming-Language/installer/tree/master/osx Last update was over 9 months ago.
Re: dmd 2.065 beta 1 #2
On 2014-01-21 23:22, Andrew Edwards wrote: Due to building an packaging requirements and a need to address the concerns of the community, I changed the naming convention for this and all future releases. The following is our new naming convention: major.minor.qualifier Examples follow: #.###.b# ==> 2.065.b1 // beta #.###.rc# ==> 2.065.rc1 // release candidate #.###.0 ==> 2.065.0 // initial release #.###.# ==> 2.065.1 // hotfix Consequently, the name for the previously announced beta has changed. Additionally, installers were prepared and made available. They are as follows: ftp://ftp.digitalmars.com/dmd.2.065.b1.zip Regression: https://d.puremagic.com/issues/show_bug.cgi?id=11966 -- /Jacob Carlborg
Re: dmd 2.065 beta 1 #2
El 22/01/14 09:31, deadalnix ha escrit: > On Wednesday, 22 January 2014 at 08:25:05 UTC, Jordi Sayol wrote: >> 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 > > Please, this has been discussed to death already. Nobody care what anybody > prefers. Unless you have an actual reason to ask for a format change (fit > better with current packaging systems for instance) please restrain yourself. > Please, if you don't like this proposed change based on a real problem on Debian and not on my "prefers", refute it with arguments but do not tell me that I should keep quiet. -- Jordi Sayol
Re: dmd 2.065 beta 1 #2
On 2014-01-21 23:22, Andrew Edwards wrote: ftp://ftp.digitalmars.com/dmd.2.065.b1.zip I manged to open this with the zip moulde in Tango now :) The previous beta failed. ftp://ftp.digitalmars.com/dmd.2.065.b1.dmg The installer is old. The text contains links to D1. The content seem to be correct though. How are you building the installer. -- /Jacob Carlborg
Re: dmd 2.065 beta 1 #2
On Wednesday, 22 January 2014 at 08:25:05 UTC, Jordi Sayol wrote: 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 Please, this has been discussed to death already. Nobody care what anybody prefers. Unless you have an actual reason to ask for a format change (fit better with current packaging systems for instance) please restrain yourself.
Re: dmd 2.065 beta 1 #2
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 -- Jordi Sayol
Re: dmd 2.065 beta 1 #2
On 2014-01-22 01:19, Leandro Lucarella wrote: Why not use semver? http://semver.org/ 2.65.0-b1 2.65.0-rc1 2.65.0 2.65.1 Then you would have versions number looking like this: 3.0.0 4.0.0 5.0.0 If we don't want to add a fourth digit. -- /Jacob Carlborg
Re: dmd 2.065 beta 1 #2
On Wed, Jan 22, 2014 at 2:19 AM, Leandro Lucarella wrote: > Jordi Sayol, el 22 de January a las 00:16 me escribiste: > > If we upgrade the version scheme, we can remove the initial zero too: > > > > 2.65.b1 > > 2.65.rc1 > > 2.65.0 > > 2.65.1 > > Why not use semver? http://semver.org/ +1 this is an obvious choice why re-invent something that is not as good as a already existing standard
Re: dmd 2.065 beta 1 #2
"Andrew Edwards" wrote in message news:lbmru9$290b$1...@digitalmars.com... ftp://ftp.digitalmars.com/dmd.2.065.b1.zip While you're at it, can we get per-platform zips? Just take the normal zip and delete all but one platform.
Re: dmd 2.065 beta 1 #2
On 1/21/14, 5:29 PM, Brad Anderson wrote: On Tuesday, 21 January 2014 at 22:22:01 UTC, Andrew Edwards wrote: Note: An installer is not yet prepared for Windows. Let me know if you need any guidance on getting the Windows installer working. Please use the one in windows/dinstaller.nsi (I need to get some free time to unify that with Jordi's windows installer in the linux folder). 1) The link for nsisunz.zip per readme.txt does not work. I found a copy here: http://code.google.com/p/pidgin-dep-easyinstaller/downloads/detail?name=nsisunz.zip&can=2&q= 2) The makefile assumes /cbx/VERSION and /cbx/VERSION1 exists. This should be documented in readme.txt.
Re: dmd 2.065 beta 1 #2
On 1/21/14, 5:22 PM, Andrew Edwards wrote: Note: An installer is not yet prepared for Windows. It is now added: ftp://ftp.digitalmars.com/dmd-2.065.b1.exe
Re: dmd 2.065 beta 1 #2
On Tue, 21 Jan 2014 20:06:31 -0500, Andrew Edwards wrote: 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 suggest to leave the naming convention alone, but to alter the deb package id for the release candidates. It should not affect mainstream users who only install released versions. -Steve
Re: dmd 2.065 beta 1 #2
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. Regards, Andrew
Re: dmd 2.065 beta 1 #2
Jordi Sayol, el 22 de January a las 00:16 me escribiste: > If we upgrade the version scheme, we can remove the initial zero too: > > 2.65.b1 > 2.65.rc1 > 2.65.0 > 2.65.1 Why not use semver? http://semver.org/ 2.65.0-b1 2.65.0-rc1 2.65.0 2.65.1 For Debian packages simply s/-/~/ and everything works as expected. -- Leandro Lucarella (AKA luca) http://llucax.com.ar/ -- GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05) -- Your success is measured by your ability to finish things
Re: dmd 2.065 beta 1 #2
If we upgrade the version scheme, we can remove the initial zero too: 2.65.b1 2.65.rc1 2.65.0 2.65.1 -- Jordi Sayol
Re: dmd 2.065 beta 1 #2
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" -- Jordi Sayol
Re: dmd 2.065 beta 1 #2
El 21/01/14 23:29, Brad Anderson ha escrit: > Please use the one in windows/dinstaller.nsi (I need to get some free time to > unify that with Jordi's windows installer in the linux folder). Windows installer from Linux folder is out of the building process. The only one windows installer is in windows/ folder. -- Jordi Sayol
Re: dmd 2.065 beta 1 #2
On Tuesday, 21 January 2014 at 22:22:01 UTC, Andrew Edwards wrote: Due to building an packaging requirements and a need to address the concerns of the community, I changed the naming convention for this and all future releases. The following is our new naming convention: major.minor.qualifier Examples follow: #.###.b# ==> 2.065.b1 // beta #.###.rc# ==> 2.065.rc1 // release candidate #.###.0 ==> 2.065.0 // initial release #.###.# ==> 2.065.1 // hotfix +1 Consequently, the name for the previously announced beta has changed. Additionally, installers were prepared and made available. They are as follows: ftp://ftp.digitalmars.com/dmd.2.065.b1.zip ftp://ftp.digitalmars.com/dmd.2.065.b1.dmg ftp://ftp.digitalmars.com/dmd_2.065.b1-0_i386.deb ftp://ftp.digitalmars.com/dmd_2.065.b1-0_amd64.deb ftp://ftp.digitalmars.com/dmd-2.065.b1-0.fedora.i386.rpm ftp://ftp.digitalmars.com/dmd-2.065.b1-0.fedora.x86_64.rpm ftp://ftp.digitalmars.com/dmd-2.065.b1-0.openSUSE.i386.rpm ftp://ftp.digitalmars.com/dmd-2.065.b1-0.openSUSE.x86_64.rpm For a description of these packages, visit http://dlang.org/downloads.html. Note: An installer is not yet prepared for Windows. Let me know if you need any guidance on getting the Windows installer working. Please use the one in windows/dinstaller.nsi (I need to get some free time to unify that with Jordi's windows installer in the linux folder). Regards, Andrew
dmd 2.065 beta 1 #2
Due to building an packaging requirements and a need to address the concerns of the community, I changed the naming convention for this and all future releases. The following is our new naming convention: major.minor.qualifier Examples follow: #.###.b# ==> 2.065.b1 // beta #.###.rc# ==> 2.065.rc1 // release candidate #.###.0 ==> 2.065.0 // initial release #.###.# ==> 2.065.1 // hotfix Consequently, the name for the previously announced beta has changed. Additionally, installers were prepared and made available. They are as follows: ftp://ftp.digitalmars.com/dmd.2.065.b1.zip ftp://ftp.digitalmars.com/dmd.2.065.b1.dmg ftp://ftp.digitalmars.com/dmd_2.065.b1-0_i386.deb ftp://ftp.digitalmars.com/dmd_2.065.b1-0_amd64.deb ftp://ftp.digitalmars.com/dmd-2.065.b1-0.fedora.i386.rpm ftp://ftp.digitalmars.com/dmd-2.065.b1-0.fedora.x86_64.rpm ftp://ftp.digitalmars.com/dmd-2.065.b1-0.openSUSE.i386.rpm ftp://ftp.digitalmars.com/dmd-2.065.b1-0.openSUSE.x86_64.rpm For a description of these packages, visit http://dlang.org/downloads.html. Note: An installer is not yet prepared for Windows. Regards, Andrew