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