subject:"dmd 2.065 beta 1"

On Wednesday, 22 January 2014 at 03:43:51 UTC, Andrew Edwards 
wrote:

1) The link for nsisunz.zip per readme.txt does not work.


I wrote the author of the plugin.

Re: dmd 2.065 beta 1 #2


On Thursday, 23 January 2014 at 06:50:47 UTC, Brad Anderson wrote:

This of course is relying on the zip file getting uploaded to
downloads.dlang.org.  You could use the digitalmars urls for
betas, I suppose, since those don't end up on the download site
anyway.  The url template is just a bit further down in the 
file.


Please no manual steps. Is it possible to do this in the nsi 
script?

Re: dmd 2.065 beta 1 #2

2014-01-23 Thread Daniel Murphy

Martin Nowak  wrote in message 
news:jcszzsgkwldowcmwz...@forum.dlang.org...
Mmh, we could simply upload the intermediate zip files for each platform, 
that fall out of create_dmd_release before they are combined.


Sounds good.

Re: dmd 2.065 beta 1 #2

2014-01-23 Thread Leandro Lucarella

Jacob Carlborg, el 23 de January a las 11:39 me escribiste:
 On 2014-01-23 10:15, Mathias LANG wrote:
 
 As Jacob already said, we will either need to go back to a major of 0,
 or improve our major number almost everytime there is a release.
 
 Ruby has just adopted the semantic versioning scheme[1] . They added
 a fourth digit. The first digit will be the version of the language,
 the remaining three digits will work as the regular semantic
 versioning scheme.
 
 [1] 
 https://www.ruby-lang.org/en/news/2013/12/21/semantic-versioning-after-2-1-0/

Works for me.

-- 
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
--
Software is like sex: it's better when it's free.
-- Linus Torvalds

Re: dmd 2.065 beta 1 #2


On 01/23/2014 01:33 PM, Dejan Lekic wrote:




It would be nice, IMHO, to have release information in the same fashion
VisualD does it. Check:
https://github.com/D-Programming-Language/visuald/releases . Notice that
each release has changelog. -Very nice and professional I think.


Yeah, maybe we can do something useful with the github release page.
We do already have a changelog though,  http://dlang.org/changelog.html.

Re: dmd 2.065 beta 1 #2

2014-01-23 Thread Brad Anderson

On Wednesday, 22 January 2014 at 03:43:51 UTC, Andrew Edwards 
wrote:

On 1/21/14, 5:29 PM, Brad Anderson wrote:
On Tuesday, 21 January 2014 at 22:22:01 UTC, Andrew Edwards 
wrote:


Note: An installer is not yet prepared for Windows.



Let me know if you need any guidance on getting the Windows 
installer
working. Please use the one in windows/dinstaller.nsi (I need 
to get
some free time to unify that with Jordi's windows installer in 
the linux

folder).



1) The link for nsisunz.zip per readme.txt does not work.



Very common with NSIS, unfortunately.  It's kind of a ghetto.

Re: dmd 2.065 beta 1 #2

2014-01-23 Thread Brad Anderson


On Thursday, 23 January 2014 at 13:29:31 UTC, Martin Nowak wrote:
On Thursday, 23 January 2014 at 06:50:47 UTC, Brad Anderson 
wrote:

This of course is relying on the zip file getting uploaded to
downloads.dlang.org.  You could use the digitalmars urls for
betas, I suppose, since those don't end up on the download site
anyway.  The url template is just a bit further down in the 
file.


Please no manual steps. Is it possible to do this in the nsi 
script?


Well, presumably Andrew will get access to upload to the download 
site at some point soon and he's just use that instead of 
digitalmars's FTP and this won't be a problem.


The NSIS script already requires a bit of manual editing 
(basically just updating the version number). I think I can 
probably figure out a way to do away with that though (NSIS can 
pull definitions from a separate file and the NSIS command line 
supports specifying definitions). I'll experiment with these soon 
and see what I can do to allow it to be completely automated.

Re: dmd 2.065 beta 1 #2

2014-01-23 Thread Jordi Sayol

El 24/01/14 00:24, Brad Anderson ha escrit:
 On Thursday, 23 January 2014 at 13:29:31 UTC, Martin Nowak wrote:
 On Thursday, 23 January 2014 at 06:50:47 UTC, Brad Anderson wrote:
 This of course is relying on the zip file getting uploaded to
 downloads.dlang.org.  You could use the digitalmars urls for
 betas, I suppose, since those don't end up on the download site
 anyway.  The url template is just a bit further down in the file.

 Please no manual steps. Is it possible to do this in the nsi script?
 
 Well, presumably Andrew will get access to upload to the download site at 
 some point soon and he's just use that instead of digitalmars's FTP and this 
 won't be a problem.
 
 The NSIS script already requires a bit of manual editing (basically just 
 updating the version number). I think I can probably figure out a way to do 
 away with that though (NSIS can pull definitions from a separate file and the 
 NSIS command line supports specifying definitions). I'll experiment with 
 these soon and see what I can do to allow it to be completely automated.
 

You can take a look on linux/win/installer.nsi that get version argument from 
linux/dmd_win.sh and therefore from command line.
 
-- 
Jordi Sayol

Re: dmd 2.065 beta 1 #2


On 01/22/2014 02:37 PM, Sönke Ludwig wrote:

I'm getting deprecation warnings inside std.datetime to use any
instead of canFind.


https://github.com/D-Programming-Language/phobos/pull/1876

Re: dmd 2.065 beta 1 #2

2014-01-23 Thread vitaly_m


On Tuesday, 21 January 2014 at 22:22:01 UTC, Andrew Edwards wrote:
For a description of these packages, visit 
http://dlang.org/downloads.html.


The link should be http://dlang.org/download.html (no 's' before
.html)

Re: dmd 2.065 beta 1 #2

2014-01-23 Thread Andrew Edwards


On 1/23/14, 7:25 PM, vitaly_m wrote:

On Tuesday, 21 January 2014 at 22:22:01 UTC, Andrew Edwards wrote:

For a description of these packages, visit
http://dlang.org/downloads.html.


The link should be http://dlang.org/download.html (no 's' before
.html)


Thanks

Re: dmd 2.065 beta 1 #2

2014-01-23 Thread Brad Anderson


On Thursday, 23 January 2014 at 23:44:09 UTC, Jordi Sayol wrote:

El 24/01/14 00:24, Brad Anderson ha escrit:
On Thursday, 23 January 2014 at 13:29:31 UTC, Martin Nowak 
wrote:
On Thursday, 23 January 2014 at 06:50:47 UTC, Brad Anderson 
wrote:

This of course is relying on the zip file getting uploaded to
downloads.dlang.org.  You could use the digitalmars urls for
betas, I suppose, since those don't end up on the download 
site
anyway.  The url template is just a bit further down in the 
file.


Please no manual steps. Is it possible to do this in the nsi 
script?


Well, presumably Andrew will get access to upload to the 
download site at some point soon and he's just use that 
instead of digitalmars's FTP and this won't be a problem.


The NSIS script already requires a bit of manual editing 
(basically just updating the version number). I think I can 
probably figure out a way to do away with that though (NSIS 
can pull definitions from a separate file and the NSIS command 
line supports specifying definitions). I'll experiment with 
these soon and see what I can do to allow it to be completely 
automated.




You can take a look on linux/win/installer.nsi that get version 
argument from linux/dmd_win.sh and therefore from command line.




Ok, cool.  I'll take a look there.

Re: dmd 2.065 beta 1 #2

2014-01-23 Thread Sönke Ludwig


Am 23.01.2014 10:38, schrieb Walter Bright:

On 1/22/2014 5:37 AM, Sönke Ludwig wrote:

(...)

There is also a build issue that sometimes occurred at the same place
in 2.064
in the form of template instantiation failures and now produces linker
errors:
https://github.com/rejectedsoftware/vibe.d/issues/458


Did you try the -allinst flag?


Tried it, but it didn't make a difference. I'm running Dustmite on it 
now, but that will take a while to complete.






Finally, I'm getting some recursive alias errors that I managed to
circumvent
in previous releases.

I'm going to run dustmite on these two and create bugzilla issues.


Unfortunately, in case of the recursive alias error, Dustmite reduced to 
a case that fails for both, 2.065 and 2.064. Also, every little change 
from there either fixes the error or makes it appear again. This is 
obviously stabbing too deep in unspecified language territory. I gave up 
on it and am now in the process of completely rewriting the affected code.

Re: dmd 2.065 beta 1 #2


On 2014-01-22 01:19, Leandro Lucarella wrote:


Why not use semver? http://semver.org/

2.65.0-b1
2.65.0-rc1
2.65.0
2.65.1


Then you would have versions number looking like this:

3.0.0
4.0.0
5.0.0

If we don't want to add a fourth digit.

--
/Jacob Carlborg

Re: dmd 2.065 beta 1 #2

2014-01-22 Thread Jordi Sayol

El 22/01/14 02:06, Andrew Edwards ha escrit:
 On 1/21/14, 6:02 PM, Jordi Sayol wrote:
 El 21/01/14 23:29, Brad Anderson ha escrit:
  #.###.~b#  == 2.065.b1  // beta
  #.###.~rc# == 2.065.rc1 // release candidate
  #.###.0   == 2.065.0   // initial release
  #.###.#   == 2.065.1   // hotfix

 On Debian, 2.065.rc1 is bigger than 2.065.0, so if 
 dmd_2.065.rc1-0_amd64.deb is installed and you try to upgrade to 
 dmd_2.065.0-0_amd64.deb, system will answer something like You have 
 installed a newer version.

 No problem if these deb packages are for internal use and test, but not for 
 a public download.

 $ dpkg --compare-versions 2.065.0 gt 2.065.rc1  echo Bigger || echo 
 Not bigger

 
 Apparently the same problem exists on FreeBSD. The first solution that comes 
 to mind is to prefix the qualifiers for betas and release candidates with a 
 tilde. As such:
 
 2.065~b1
 2.065~rc1
 
 or:
 
 2.065.~b1
 2.065.~rc1
 
 This solution works on both Ubuntu and FreeBSD but I'm not sure it is the 
 right one. Suggestions are welcomed.

I prefer:

2.65~b1
2.65~rc1

because 2.65.0 and 2.65 are bigger than 2.65~rc1, regardless if 
qualifier number is present or not in final release version.

I think that, as much as possible, we should use exactly the same version 
string for all installers, zip, deb, rpm, dmg, etc.
So if there is no problem on OSX, Windows, etc. I propose this versioning 
scheme:

#.#~b#  == 2.65~b1  // beta
#.#~rc# == 2.65~rc1 // release candidate
#.#.#   == 2.65.0   // initial release
#.#.#   == 2.65.1   // hotfix

-- 
Jordi Sayol

Re: dmd 2.065 beta 1 #2

2014-01-22 Thread deadalnix


On Wednesday, 22 January 2014 at 08:25:05 UTC, Jordi Sayol wrote:

I prefer:

2.65~b1
2.65~rc1

because 2.65.0 and 2.65 are bigger than 2.65~rc1, 
regardless if qualifier number is present or not in final 
release version.


I think that, as much as possible, we should use exactly the 
same version string for all installers, zip, deb, rpm, dmg, etc.
So if there is no problem on OSX, Windows, etc. I propose this 
versioning scheme:


#.#~b#  == 2.65~b1  // beta
#.#~rc# == 2.65~rc1 // release candidate
#.#.#   == 2.65.0   // initial release
#.#.#   == 2.65.1   // hotfix


Please, this has been discussed to death already. Nobody care 
what anybody prefers. Unless you have an actual reason to ask for 
a format change (fit better with current packaging systems for 
instance) please restrain yourself.

Re: dmd 2.065 beta 1 #2


On 2014-01-21 23:22, Andrew Edwards wrote:


 ftp://ftp.digitalmars.com/dmd.2.065.b1.zip


I manged to open this with the zip moulde in Tango now :) The previous 
beta failed.



 ftp://ftp.digitalmars.com/dmd.2.065.b1.dmg


The installer is old. The text contains links to D1. The content seem to 
be correct though. How are you building the installer.


--
/Jacob Carlborg

Re: dmd 2.065 beta 1 #2

2014-01-22 Thread Jordi Sayol

El 22/01/14 09:31, deadalnix ha escrit:
 On Wednesday, 22 January 2014 at 08:25:05 UTC, Jordi Sayol wrote:
 I prefer:

 2.65~b1
 2.65~rc1

 because 2.65.0 and 2.65 are bigger than 2.65~rc1, regardless if 
 qualifier number is present or not in final release version.

 I think that, as much as possible, we should use exactly the same version 
 string for all installers, zip, deb, rpm, dmg, etc.
 So if there is no problem on OSX, Windows, etc. I propose this versioning 
 scheme:

 #.#~b#  == 2.65~b1  // beta
 #.#~rc# == 2.65~rc1 // release candidate
 #.#.#   == 2.65.0   // initial release
 #.#.#   == 2.65.1   // hotfix
 
 Please, this has been discussed to death already. Nobody care what anybody 
 prefers. Unless you have an actual reason to ask for a format change (fit 
 better with current packaging systems for instance) please restrain yourself.
 

Please, if you don't like this proposed change based on a real problem on 
Debian and not on my prefers, refute it with arguments but do not tell me 
that I should keep quiet.

-- 
Jordi Sayol

Re: dmd 2.065 beta 1 #2

2014-01-22 Thread Andrew Edwards


On 1/22/14, 3:38 AM, Jacob Carlborg wrote:

On 2014-01-21 23:22, Andrew Edwards wrote:


 ftp://ftp.digitalmars.com/dmd.2.065.b1.dmg


The installer is old. The text contains links to D1. The content seem to
be correct though. How are you building the installer.



That might be the case. I'm following the instructions here:

https://github.com/D-Programming-Language/installer/tree/master/osx

Last update was over 9 months ago.

Re: dmd 2.065 beta 1 #2

2014-01-22 Thread Leandro Lucarella

Andrew Edwards, el 21 de January a las 20:06 me escribiste:
 On 1/21/14, 6:02 PM, Jordi Sayol wrote:
 El 21/01/14 23:29, Brad Anderson ha escrit:
  #.###.~b#  == 2.065.b1  // beta
  #.###.~rc# == 2.065.rc1 // release candidate
  #.###.0   == 2.065.0   // initial release
  #.###.#   == 2.065.1   // hotfix
 
 On Debian, 2.065.rc1 is bigger than 2.065.0, so if 
 dmd_2.065.rc1-0_amd64.deb is installed and you try to upgrade to 
 dmd_2.065.0-0_amd64.deb, system will answer something like You have 
 installed a newer version.
 
 No problem if these deb packages are for internal use and test, but not for 
 a public download.
 
 $ dpkg --compare-versions 2.065.0 gt 2.065.rc1  echo Bigger || echo 
 Not bigger
 
 
 Apparently the same problem exists on FreeBSD. The first solution
 that comes to mind is to prefix the qualifiers for betas and release
 candidates with a tilde. As such:
 
   2.065~b1
   2.065~rc1
 
 or:
 
   2.065.~b1
   2.065.~rc1
 
 This solution works on both Ubuntu and FreeBSD but I'm not sure it
 is the right one. Suggestions are welcomed.

There is a fairly popular de-facto standard for versioning: semver. Yes,
it is incompatible with Debian (and I guess FreeBSD) but you can make
it compatible by just changing one character (- - ~).

Since apparently a version naming scheme is needed, does anyone have
a good reason NOT to use a standard that's easily adaptable to several
popular distributions?

-- 
Leandro Lucarella (AKA luca) http://llucax.com.ar/

Re: dmd 2.065 beta 1

2014-01-22 Thread Dejan Lekic


On Tuesday, 21 January 2014 at 20:48:27 UTC, Andrew Edwards wrote:

On 1/21/14, 2:20 PM, Dejan Lekic wrote:
Can we *please* have a well-established, useful, naming scheme 
for tags and
packages? 2.064beta3, 2.064beta4, 2.064.2, 2.065-b1... Are you 
as frustrated as

me?


I was just in the process of addressing this. Based on recent 
issues with using the packaging scripts, I've changed the 
naming convention as follows:


#.###.b#// beta
#.###.rc#   // release candidate
#.#.0   // release
#.#.#   // hotfix (where last # != 0)

That should solve any issues you may have.


That is absolutely briliant Andrew! Now we can use my SPEC file 
to build new DMD RPMs whenever there is a new release (tag) on 
GitHub!

Re: dmd 2.065 beta 1 #2


On 2014-01-22 13:16, Andrew Edwards wrote:


That might be the case. I'm following the instructions here:

 https://github.com/D-Programming-Language/installer/tree/master/osx

Last update was over 9 months ago.


https://github.com/D-Programming-Language/installer/pull/44

--
/Jacob Carlborg

Re: dmd 2.065 beta 1 #2


On 2014-01-21 23:22, Andrew Edwards wrote:

Due to building an packaging requirements and a need to address the
concerns of the community, I changed the naming convention for this and
all future releases.


I'm getting some regressions when compiling Tango. I filed one bug 
report but having trouble creating a reduced test case for the other one.


The error I get is:

Regex.d(2524): Error: associative array key type TagIndex does not have 
'const int opCmp(ref const TagIndex)' member function
Regex.d(3676): Error: template instance tango.text.Regex.TDFA!dchar 
error instantiating

Regex.d(4420):instantiated from here: RegExpT!char
Regex.d(4407): Error: tdfa_t.Command is used as a type
Regex.d(4420): Error: template instance tango.text.Regex.RegExpT!char 
error instantiating


TagIndex looks like this:

struct TagIndex
{
uint tag, index;
}

And it's used in an associative array:

uint[TagIndex] registers;

--
/Jacob Carlborg

Re: dmd 2.065 beta 1 #2

2014-01-22 Thread Brad Anderson


On Wednesday, 22 January 2014 at 03:34:40 UTC, Andrew Edwards
wrote:

On 1/21/14, 5:22 PM, Andrew Edwards wrote:


Note: An installer is not yet prepared for Windows.



It is now added: ftp://ftp.digitalmars.com/dmd-2.065.b1.exe


This of course is relying on the zip file getting uploaded to
downloads.dlang.org.  You could use the digitalmars urls for
betas, I suppose, since those don't end up on the download site
anyway.  The url template is just a bit further down in the file.

Re: dmd 2.065 beta 1

2014-01-21 Thread eles


On Tuesday, 21 January 2014 at 00:30:30 UTC, bearophile wrote:

Andrew Edwards:

When submitting bug reports associated with this review, 
ensure they are earmarked [REG2.065-b1] or [BUG2.065-b1] for 
easy identification, retrieval and merger.


So far I am not finding many bugs in this. But when is the work 
on 2.066 going to start? There are many patches. And what's the 
focus (if it has one) of D 2.066? I suggest to warn/deprecate 
all that should be deprecated (built-in sort, old operator 
overloading, etc), and introduce some of the little breaking


complex numbers
-property

Re: dmd 2.065 beta 1

2014-01-21 Thread Dejan Lekic

Andrew Edwards wrote:

Beta testing for dmd 2.065 is under way. You can access the associated
zip at [1] and view the current list of regressions at [2]. Make every
effort to provide a thorough review so we can get the best product out
the door.

Please refrain from discussing the review here in the dlang.org forums.
Instead, post all concerns to the dmd-beta mailing list at [3]. If you
haven't already done so, you will need to register to the mailing list
at [4].

When submitting bug reports associated with this review, ensure they are
earmarked [REG2.065-b1] or [BUG2.065-b1] for easy identification,
retrieval and merger.

[1] ftp://ftp.digitalmars.com/dmd.2.065.beta.1.zip
[2]

http://d.puremagic.com/issues/buglist.cgi?query_format=advancedbug_severity=regressionbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENED
[3] http://forum.dlang.org/group/dmd-beta
[4] http://lists.puremagic.com/mailman/listinfo/dmd-beta

Can we *please* have a well-established, useful, naming scheme for tags and
packages? 2.064beta3, 2.064beta4, 2.064.2, 2.065-b1... Are you as frustrated as
me?

For starters, you guys should first decide should we have micro part of the
version at all? (major.minor.micro-qualifier) Please decide a schema and all
cases should be covered by it, including betas or what I would rather call
candidate-releases or release-candidates.

From a standpoint of a RPM author - what I refer to as the qualifier (that
is
how OSGI names it) is basically a build-number of the package. Sometimes we,
package maintaners have to rebuild set of packages because some configuration
parameter had to be changed, or some file was missing, etc. Upstream should
never specify this value. What upstream people should specify are major, minor
and micro values. So, whatever you name your beta/rc/cr etc, please stick to
the
naming convention, otherwise it is going to make our life difficult.

I propose you name/tag the latest DMD package like the following: 2.065.rc1 .
When release comes up, it will be tagged 2.065.0 if there are 2.065 hotfix
releases, they should be tagged 2.065.1, 2.065.2, etc.

This is not my invention - smarted people than me come up with this, for a good
reason.

--
Dejan Lekic
dejan.lekic (a) gmail.com
http://dejan.lekic.org

Re: dmd 2.065 beta 1


On 1/21/14, 2:20 PM, Dejan Lekic wrote:

Can we *please* have a well-established, useful, naming scheme for tags and
packages? 2.064beta3, 2.064beta4, 2.064.2, 2.065-b1... Are you as frustrated as
me?


I was just in the process of addressing this. Based on recent issues 
with using the packaging scripts, I've changed the naming convention as 
follows:


#.###.b#// beta
#.###.rc#   // release candidate
#.#.0   // release
#.#.#   // hotfix (where last # != 0)

That should solve any issues you may have.

Re: dmd 2.065 beta 1

2014-01-21 Thread deadalnix


On Tuesday, 21 January 2014 at 20:48:27 UTC, Andrew Edwards wrote:

On 1/21/14, 2:20 PM, Dejan Lekic wrote:
Can we *please* have a well-established, useful, naming scheme 
for tags and
packages? 2.064beta3, 2.064beta4, 2.064.2, 2.065-b1... Are you 
as frustrated as

me?


I was just in the process of addressing this. Based on recent 
issues with using the packaging scripts, I've changed the 
naming convention as follows:


#.###.b#// beta
#.###.rc#   // release candidate
#.#.0   // release
#.#.#   // hotfix (where last # != 0)

That should solve any issues you may have.


Thank !

dmd 2.065 beta 1 #2

Due to building an packaging requirements and a need to address the 
concerns of the community, I changed the naming convention for this and 
all future releases.


The following is our new naming convention:

major.minor.qualifier

Examples follow:

#.###.b#  == 2.065.b1  // beta
#.###.rc# == 2.065.rc1 // release candidate
#.###.0   == 2.065.0   // initial release
#.###.#   == 2.065.1   // hotfix

Consequently, the name for the previously announced beta has changed. 
Additionally, installers were prepared and made available. They are as 
follows:


ftp://ftp.digitalmars.com/dmd.2.065.b1.zip
ftp://ftp.digitalmars.com/dmd.2.065.b1.dmg
ftp://ftp.digitalmars.com/dmd_2.065.b1-0_i386.deb
ftp://ftp.digitalmars.com/dmd_2.065.b1-0_amd64.deb
ftp://ftp.digitalmars.com/dmd-2.065.b1-0.fedora.i386.rpm
ftp://ftp.digitalmars.com/dmd-2.065.b1-0.fedora.x86_64.rpm
ftp://ftp.digitalmars.com/dmd-2.065.b1-0.openSUSE.i386.rpm
ftp://ftp.digitalmars.com/dmd-2.065.b1-0.openSUSE.x86_64.rpm

For a description of these packages, visit http://dlang.org/downloads.html.

Note: An installer is not yet prepared for Windows.

Regards,
Andrew

Re: dmd 2.065 beta 1 #2

2014-01-21 Thread Brad Anderson


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

Re: dmd 2.065 beta 1 #2

2014-01-21 Thread Jordi Sayol

El 21/01/14 23:29, Brad Anderson ha escrit:
 Please use the one in windows/dinstaller.nsi (I need to get some free time to 
 unify that with Jordi's windows installer in the linux folder).

Windows installer from Linux folder is out of the building process. The only 
one windows installer is in windows/ folder.

-- 
Jordi Sayol

Re: dmd 2.065 beta 1 #2

2014-01-21 Thread Jordi Sayol

If we upgrade the version scheme, we can remove the initial zero too:

2.65.b1
2.65.rc1
2.65.0
2.65.1

-- 
Jordi Sayol

Re: dmd 2.065 beta 1 #2


On 1/21/14, 6:02 PM, Jordi Sayol wrote:

El 21/01/14 23:29, Brad Anderson ha escrit:

 #.###.~b#  == 2.065.b1  // beta
 #.###.~rc# == 2.065.rc1 // release candidate
 #.###.0   == 2.065.0   // initial release
 #.###.#   == 2.065.1   // hotfix


On Debian, 2.065.rc1 is bigger than 2.065.0, so if dmd_2.065.rc1-0_amd64.deb is installed and 
you try to upgrade to dmd_2.065.0-0_amd64.deb, system will answer something like You have installed a newer 
version.

No problem if these deb packages are for internal use and test, but not for a 
public download.

$ dpkg --compare-versions 2.065.0 gt 2.065.rc1  echo Bigger || echo Not 
bigger



Apparently the same problem exists on FreeBSD. The first solution that 
comes to mind is to prefix the qualifiers for betas and release 
candidates with a tilde. As such:


2.065~b1
2.065~rc1

or:

2.065.~b1
2.065.~rc1

This solution works on both Ubuntu and FreeBSD but I'm not sure it is 
the right one. Suggestions are welcomed.


Regards,
Andrew

Re: dmd 2.065 beta 1 #2

2014-01-21 Thread Leandro Lucarella

Jordi Sayol, el 22 de January a las 00:16 me escribiste:
 If we upgrade the version scheme, we can remove the initial zero too:
 
 2.65.b1
 2.65.rc1
 2.65.0
 2.65.1

Why not use semver? http://semver.org/

2.65.0-b1
2.65.0-rc1
2.65.0
2.65.1

For Debian packages simply s/-/~/ and everything works as expected.

-- 
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145  104C 949E BFB6 5F5A 8D05)
--
Your success is measured by your ability to finish things

Re: dmd 2.065 beta 1 #2

2014-01-21 Thread Steven Schveighoffer

On Tue, 21 Jan 2014 20:06:31 -0500, Andrew Edwards rid...@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

Re: dmd 2.065 beta 1 #2


On 1/21/14, 5:22 PM, Andrew Edwards wrote:


Note: An installer is not yet prepared for Windows.



It is now added: ftp://ftp.digitalmars.com/dmd-2.065.b1.exe

Re: dmd 2.065 beta 1 #2