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:






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:







+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:







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:







 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:







 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:







 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:






-- 
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:







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:







 
 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:







 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:







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:







 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:







 
 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:







 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:







 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:







 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:







 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:







 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:







 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:







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:






 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, 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
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 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).
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:






 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