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.

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.

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.

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?

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.

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 ... ?

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

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