www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Release D 2.074.1

reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
Glad to announce D 2.074.1.

http://dlang.org/download.html

This point release fixes a few issues over 2.074.0, see the changelog
for more details.

http://dlang.org/changelog/2.074.1.html

-Martin
Jun 01
next sibling parent Ivan Kazmenko <gassa mail.ru> writes:
On Thursday, 1 June 2017 at 21:04:00 UTC, Martin Nowak wrote:
 Glad to announce D 2.074.1.

 http://dlang.org/download.html

 This point release fixes a few issues over 2.074.0, see the 
 changelog for more details.

 http://dlang.org/changelog/2.074.1.html
Thank you for the release! I've noticed the old backend license is gone, but the summary license text at the root is still ancient and not updated. The file is, perhaps: https://github.com/dlang/installer/blob/master/create_dmd_release/extras/all/dmd2/license.txt A relevant issue: https://issues.dlang.org/show_bug.cgi?id=17317
Jun 01
prev sibling next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Thursday, 1 June 2017 at 21:04:00 UTC, Martin Nowak wrote:
 Glad to announce D 2.074.1.

 http://dlang.org/download.html

 This point release fixes a few issues over 2.074.0, see the 
 changelog for more details.

 http://dlang.org/changelog/2.074.1.html
Great news, thanks Martin. I'll update the snap packages over the weekend. :-)
Jun 02
parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Friday, 2 June 2017 at 09:52:45 UTC, Joseph Rushton Wakeling 
wrote:
 Great news, thanks Martin.  I'll update the snap packages over 
 the weekend. :-)
Done. sudo snap refresh --classic --edge dmd should upgrade things for anyone who already has the package install; otherwise, sudo snap install --classic --edge dmd will install the dmd snap package for you.
Jun 03
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2017-06-01 23:04, Martin Nowak wrote:
 Glad to announce D 2.074.1.

 http://dlang.org/download.html

 This point release fixes a few issues over 2.074.0, see the changelog
 for more details.

 http://dlang.org/changelog/2.074.1.html
Any progress on the remaining regressions [1]? [1] https://issues.dlang.org/buglist.cgi?quicksearch=%5BREG%202.074.0%5D&list_id=215151 -- /Jacob Carlborg
Jun 02
prev sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Thursday, 1 June 2017 at 21:04:00 UTC, Martin Nowak wrote:
 This point release fixes a few issues over 2.074.0, see the 
 changelog for more details.
I'm afraid that the release has another fault: the VERSION file still gives 2.074.0. This means that unless it is edited during the build process, the compiler will report the wrong version number when `dmd --version` is invoked.
Jun 03
next sibling parent reply Seb <seb wilzba.ch> writes:
On Saturday, 3 June 2017 at 18:08:40 UTC, Joseph Rushton Wakeling 
wrote:
 On Thursday, 1 June 2017 at 21:04:00 UTC, Martin Nowak wrote:
 This point release fixes a few issues over 2.074.0, see the 
 changelog for more details.
I'm afraid that the release has another fault: the VERSION file still gives 2.074.0. This means that unless it is edited during the build process, the compiler will report the wrong version number when `dmd --version` is invoked.
curl https://i.dlang.io | bash -s ~/dlang/dmd-2.074.1/linux/bin64/dmd --version DMD64 D Compiler v2.074.1 Copyright (c) 1999-2017 by Digital Mars written by Walter Bright Or even shorter:
 source $(curl https://i.dlang.io | bash -s dmd --activate) && 
 dmd --version
However, also the bundled VERSION file is correct for me:
 cat ~/dlang/dmd-2.074.1/src/VERSION
2.074.1 So, I guess your problem is the VERSION file on the dmd stable branch? https://github.com/dlang/dmd/blob/stable/VERSION According point releases have never been flagged there: https://github.com/dlang/dmd/commits/stable/VERSION Probably because it's more yet another work step & makes merging the master branch back into stable a bit more complicated. Can't you simply overwrite the VERSION file in your build process? Otherwise it's just one simple PR away ;-)
Jun 03
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Saturday, 3 June 2017 at 18:42:57 UTC, Seb wrote:
 So, I guess your problem is the VERSION file on the dmd stable 
 branch?
No, it's the VERSION file present if one checks out the v2.074.1 tag. I suspect this doesn't show up in the official packages because IIRC the VERSION file is edited as part of the standard official-package build process.
 Can't you simply overwrite the VERSION file in your build 
 process?
 Otherwise it's just one simple PR away ;-)
The point is here that this keeps happening. Assuming a VERSION file is considered necessary at all (I believe the intent is to support people using a tarball of the source rather than a git checkout), it shouldn't be possible for a release to be made without it containing the correct version number. Workarounds like this just perpetuate the problem and throw a burden on downstream packagers. Now that dmd is open-sourced and widespread packaging is feasible, it really would be preferable to fix the problem where it arises.
Jun 03
next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Saturday, 3 June 2017 at 19:02:36 UTC, Joseph Rushton Wakeling 
wrote:
 The point is here that this keeps happening.
The relevant issue (filed over a year ago): https://issues.dlang.org/show_bug.cgi?id=15910
Jun 03
prev sibling parent reply Seb <seb wilzba.ch> writes:
On Saturday, 3 June 2017 at 19:02:36 UTC, Joseph Rushton Wakeling 
wrote:
 On Saturday, 3 June 2017 at 18:42:57 UTC, Seb wrote:
 So, I guess your problem is the VERSION file on the dmd stable 
 branch?
No, it's the VERSION file present if one checks out the v2.074.1 tag.
Tags are only made from the stable branch.
 I suspect this doesn't show up in the official packages because 
 IIRC the VERSION file is edited as part of the standard 
 official-package build process.
Yes.
 The point is here that this keeps happening.  Assuming a 
 VERSION file is considered necessary at all (I believe the 
 intent is to support people using a tarball of the source 
 rather than a git checkout), it shouldn't be possible for a 
 release to be made without it containing the correct version 
 number.
Well, as mentioned minor point releases have never been changed in the git repo before: https://github.com/dlang/dmd/commits/stable/VERSION So I'm not sure how necessary it is. Anyhow, the interesting bits are here: https://github.com/dlang/installer/tree/master/create_dmd_release in particular: https://github.com/dlang/installer/blob/master/create_dmd_release/build_all.d#L494 https://gist.github.com/MartinNowak/a471fe7ddbfeef205cdf04c93a94c6d0
Jun 03
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Saturday, 3 June 2017 at 19:31:51 UTC, Seb wrote:
 Tags are only made from the stable branch.
The point is that the VERSION file is wrong in the officially tagged release source.
 Well, as mentioned minor point releases have never been changed 
 in the git repo before:

 https://github.com/dlang/dmd/commits/stable/VERSION
Yes, and this is wrong. It means that one cannot reliably build from unmodified source and wind up with a DMD that accurately describes its own version. It's a mistake that remains tolerated, despite the problem being known and having an associated issue, because the dlang/installer scripts work around it, meaning the fundamental problem never gets fixed.
 So I'm not sure how necessary it is.
The problem here is that anyone downstream wanting to build or package from source has to work around this issue, that without manual intervention, the version information of the compiler will be incorrect. If that's not fixed in how dmd itself is managed (NOT the dlang/installer scripts), this will continue to be an unnecessary burden on downstream packagers.
 Anyhow, the interesting bits are here:
I very much appreciate your pointing me to material that can help me create a workaround. But I'd feel a lot better about implementing such a workaround if I felt sure that there was a clear understanding of why it matters to fix this properly in dmd itself. Note, I don't say anything about what such a fix should be, so please don't assume that I'm asking for any particular thing to be done. (There are a variety of ideas in the open issue.) What I'm asking is that it should be possible to build from unmodified source and have correct version info in the compiler.
Jun 03
next sibling parent reply Seb <seb wilzba.ch> writes:
On Saturday, 3 June 2017 at 19:57:36 UTC, Joseph Rushton Wakeling 
wrote:
 It's a mistake that remains tolerated, despite the problem 
 being known and having an associated issue, because the 
 dlang/installer scripts work around it, meaning the fundamental 
 problem never gets fixed.
I understand the problem, but there's only so much Martin can do in his free time.
 So I'm not sure how necessary it is.
The problem here is that anyone downstream wanting to build or package from source has to work around this issue, that without manual intervention, the version information of the compiler will be incorrect.
Yep, but it's just a one-liner, right? https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/dmd#n32
 If that's not fixed in how dmd itself is managed (NOT the 
 dlang/installer scripts), this will continue to be an 
 unnecessary burden on downstream packagers.
Well, as said before _until_ there's no one volunteering to do this, it won't happen. FWIW in the past sometimes even bumping the major version has been forgotten: https://github.com/dlang/dmd/commits/master/VERSION
 I very much appreciate your pointing me to material that can 
 help me create a workaround.  But I'd feel a lot better about 
 implementing such a workaround if I felt sure that there was a 
 clear understanding of why it matters to fix this properly in 
 dmd itself.
I pointed you to the release scripts, because these are the spots where an addition to automatically update the VERSION file could be inserted ;-) For example, the PRs merging stable <-> master are generated from these scripts as well.
Jun 03
parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Saturday, 3 June 2017 at 21:17:18 UTC, Seb wrote:
 I understand the problem, but there's only so much Martin can 
 do in his free time.
I'm not asking anyone to do the work. I'm asking for a clear recognition that this is a problem that should be fixed. I'm also asking for a clear recognition that the impact of this problem is greater now that there is likely to be a greater volume of downstream packaging of dmd.
 Yep, but it's just a one-liner, right?
 https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/dmd#n32
Not the point. Workaround != fix.
 Well, as said before _until_ there's no one volunteering to do 
 this, it won't happen.
 FWIW in the past sometimes even bumping the major version has 
 been forgotten:
 https://github.com/dlang/dmd/commits/master/VERSION
I'm aware of that. All the more reason to address the fundamental problem.
 I pointed you to the release scripts, because these are the 
 spots where an addition to automatically update the VERSION 
 file could be inserted ;-)
Thanks for the heads-up, then. But I'm not sure that the best way to deal with this problem is to automate the process of patching the VERSION file. It would be better to find a way to avoid the need for the VERSION file altogether. Obvious example: if you want to promote a release candidate to the final release, it's much nicer to be able to tag the same commit, than to need to add an extra patch just to update VERSION.
Jun 03
prev sibling parent reply Martin Nowak <code dawg.eu> writes:
On Saturday, 3 June 2017 at 19:57:36 UTC, Joseph Rushton Wakeling 
wrote:
 The problem here is that anyone downstream wanting to build or 
 package from source has to work around this issue, that without 
 manual intervention, the version information of the compiler 
 will be incorrect.

 If that's not fixed in how dmd itself is managed (NOT the 
 dlang/installer scripts), this will continue to be an 
 unnecessary burden on downstream packagers.
IMO the problem here is the usage of a VERSION file in the first place, which exists only b/c it's somewhat tricky to invoke git on Windows. If your building a version, you know which one it is and can/should provide that version.
Jun 05
parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Monday, 5 June 2017 at 18:25:19 UTC, Martin Nowak wrote:
 IMO the problem here is the usage of a VERSION file in the 
 first place, which exists only b/c it's somewhat tricky to 
 invoke git on Windows.
Yup, my instinct is that if a VERSION file needs to exist at all it should be created during the build process out of `git describe` output. Apart from Windows, are there any other cases where it's still more convenient to have it up front? And what makes invoking git tricky on the Windows side?
 If your building a version, you know which one it is and 
 can/should provide that version.
Who's "you" in this scenario? :-) I think it's reasonable that e.g. an official source tarball should contain sufficient information that building it, without modification or the need for user input, will result in a compiler that reports correct version information. (Official here means the stuff available on the Downloads page, not the autogenerated tarballs that GitHub offers which are just a copy of a checkout of the git tree.) OTOH if one is building from within a git checkout, then git should be queried to provide the version info (with an option to disable/override this if the user wants to). I'd have thought those two options would cover almost all requirements out there, no ... ?
Jun 05
parent Jacob Carlborg <doob me.com> writes:
On 2017-06-05 23:38, Joseph Rushton Wakeling wrote:

 Yup, my instinct is that if a VERSION file needs to exist at all it
 should be created during the build process out of `git describe` output.
It's used by DMD to build the version, that is, the output of "dmd --version". The content of the VERSION file embedded in the executable using "import()". I don't think that's possible to do in any other way. But the VERSION file should be generated when building and not be committed to the repository. For the archives I guess it needs to be generated and included in the archive since Git will not be available when building from an archive. -- /Jacob Carlborg
Jun 06
prev sibling parent reply Martin Nowak <code dawg.eu> writes:
On Saturday, 3 June 2017 at 18:08:40 UTC, Joseph Rushton Wakeling 
wrote:
 On Thursday, 1 June 2017 at 21:04:00 UTC, Martin Nowak wrote:
 This point release fixes a few issues over 2.074.0, see the 
 changelog for more details.
I'm afraid that the release has another fault: the VERSION file still gives 2.074.0. This means that unless it is edited during the build process, the compiler will report the wrong version number when `dmd --version` is invoked.
All those VERSION files are a mess, in particular the dmd VERSION file currently gets updated at a different point than the dlang.org VERSION files. I'd like to get rid of them all and exclusively use git tags, but there are too many other use cases. Updated the release script to update the dmd VERSION file after a release. Guess it would help a bit if we bumped the dmd development version WITH the release instead of AFTER the release. Would also match what git describe does, which might be the saner version anyhow. Should we try to change that for 2.075.0?
Jun 05
parent Martin Nowak <code dawg.eu> writes:
On Monday, 5 June 2017 at 18:18:55 UTC, Martin Nowak wrote:
 Guess it would help a bit if we bumped the dmd development 
 version WITH the release instead of AFTER the release. Would 
 also match what git describe does, which might be the saner 
 version anyhow.
 Should we try to change that for 2.075.0?
https://github.com/dlang/dmd/pull/6935
Jun 25