www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dmd 2.065 beta 1 #2

reply Andrew Edwards <ridimz yahoo.com> writes:
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
Jan 21 2014
next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
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
Jan 21 2014
next sibling parent Jordi Sayol <g.sayol yahoo.es> writes:
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
Jan 21 2014
prev sibling next sibling parent reply Jordi Sayol <g.sayol yahoo.es> writes:
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
Jan 21 2014
parent reply Andrew Edwards <ridimz yahoo.com> writes:
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
Jan 21 2014
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 21 Jan 2014 20:06:31 -0500, Andrew Edwards <ridimz yahoo.com>  
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
Jan 21 2014
prev sibling next sibling parent reply Jordi Sayol <g.sayol yahoo.es> writes:
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
Jan 22 2014
next sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
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.
Jan 22 2014
parent Jordi Sayol <g.sayol yahoo.es> writes:
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
Jan 22 2014
prev sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
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
Jan 26 2014
parent reply Jordi Sayol <g.sayol yahoo.es> writes:
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
Jan 26 2014
parent reply Andrew Edwards <ridimz yahoo.com> writes:
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.
Jan 26 2014
next sibling parent reply Jordi Sayol <g.sayol yahoo.es> writes:
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
Jan 26 2014
parent reply Andrew Edwards <ridimz yahoo.com> writes:
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.
Jan 26 2014
parent reply Jordi Sayol <g.sayol yahoo.es> writes:
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
Jan 26 2014
next sibling parent Martin Nowak <code dawg.eu> writes:
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
Feb 03 2014
prev sibling parent Martin Nowak <code dawg.eu> writes:
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/lin x/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
Feb 04 2014
prev sibling next sibling parent Andrew Edwards <ridimz yahoo.com> writes:
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.
Jan 26 2014
prev sibling parent Dejan Lekic <dejan.lekic gmail.com> writes:
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
Feb 17 2014
prev sibling parent reply Leandro Lucarella <luca llucax.com.ar> writes:
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/
Jan 22 2014
parent reply "Mathias LANG" <pro.mathias.lang gmail.com> writes:
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.
Jan 23 2014
parent reply Jacob Carlborg <doob me.com> writes:
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
Jan 23 2014
parent Leandro Lucarella <luca llucax.com.ar> writes:
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
Jan 23 2014
prev sibling parent reply Andrew Edwards <ridimz yahoo.com> writes:
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.
Jan 21 2014
next sibling parent reply "Martin Nowak" <code dawg.eu> writes:
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.
Jan 23 2014
parent reply Martin Nowak <code dawg.eu> writes:
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?
Jan 24 2014
parent Andrew Edwards <ridimz yahoo.com> writes:
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.
Jan 24 2014
prev sibling parent "Brad Anderson" <eco gnuk.net> writes:
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.
Jan 23 2014
prev sibling next sibling parent reply Jordi Sayol <g.sayol yahoo.es> writes:
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
Jan 21 2014
parent reply Leandro Lucarella <luca llucax.com.ar> writes:
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
Jan 21 2014
next sibling parent Rory McGuire <rjmcguire gmail.com> writes:
On Wed, Jan 22, 2014 at 2:19 AM, Leandro Lucarella <luca llucax.com.ar>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
Jan 21 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
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
Jan 21 2014
prev sibling next sibling parent reply Andrew Edwards <ridimz yahoo.com> writes:
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
Jan 21 2014
parent reply "Brad Anderson" <eco gnuk.net> writes:
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.
Jan 22 2014
parent reply "Martin Nowak" <code dawg.eu> writes:
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?
Jan 23 2014
parent reply "Brad Anderson" <eco gnuk.net> writes:
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.
Jan 23 2014
next sibling parent reply Jordi Sayol <g.sayol yahoo.es> writes:
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
Jan 23 2014
parent "Brad Anderson" <eco gnuk.net> writes:
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.
Jan 23 2014
prev sibling parent Martin Nowak <code dawg.eu> writes:
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.
Jan 24 2014
prev sibling next sibling parent reply "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"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.
Jan 21 2014
parent reply "Martin Nowak" <code dawg.eu> writes:
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.
Jan 23 2014
next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Martin Nowak"  wrote in message 
news:jcszzsgkwldowcmwzooa 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.
Jan 23 2014
prev sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Martin Nowak"  wrote in message 
news:jcszzsgkwldowcmwzooa 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.
Jan 26 2014
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Jan 22 2014
parent reply Andrew Edwards <ridimz yahoo.com> writes:
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.
Jan 22 2014
next sibling parent Jacob Carlborg <doob me.com> writes:
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
Jan 22 2014
prev sibling parent Jacob Carlborg <doob me.com> writes:
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
Jan 22 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
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
Jan 22 2014
prev sibling next sibling parent reply =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig+dforum outerproduct.org> writes:
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.
Jan 22 2014
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 23 2014
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
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.
Jan 23 2014
prev sibling next sibling parent Martin Nowak <code dawg.eu> writes:
On 01/22/2014 02:37 PM, Snke 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
Jan 23 2014
prev sibling next sibling parent reply "Don" <x nospam.com> writes:
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; }
Jan 27 2014
parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig+dforum outerproduct.org> writes:
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?
Jan 27 2014
prev sibling parent =?ISO-8859-1?Q?S=F6nke_Ludwig?= <sludwig+dforum outerproduct.org> writes:
Am 22.01.2014 14:37, schrieb Snke 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).
Jan 27 2014
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
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
Jan 22 2014
prev sibling next sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
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.
Jan 23 2014
parent Martin Nowak <code dawg.eu> writes:
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.
Jan 23 2014
prev sibling next sibling parent reply "vitaly_m" <restlessmonkey ya.ru> writes:
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)
Jan 23 2014
parent Andrew Edwards <ridimz yahoo.com> writes:
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
Jan 23 2014
prev sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
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?
Jan 24 2014
parent reply Andrew Edwards <ridimz yahoo.com> writes:
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.
Jan 24 2014
parent "deadalnix" <deadalnix gmail.com> writes:
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.
Jan 25 2014