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

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

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

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

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.

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 ;-)

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.

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

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

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.