Re: Release D 2.074.1

2017-06-06 Thread Jacob Carlborg via Digitalmars-d-announce

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


Re: Release D 2.074.1

2017-06-05 Thread Joseph Rushton Wakeling via Digitalmars-d-announce

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


Re: Release D 2.074.1

2017-06-05 Thread Martin Nowak via Digitalmars-d-announce
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.




Re: Release D 2.074.1

2017-06-05 Thread Martin Nowak via Digitalmars-d-announce
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?


Re: Release D 2.074.1

2017-06-03 Thread Joseph Rushton Wakeling via Digitalmars-d-announce
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.


Re: Release D 2.074.1

2017-06-03 Thread Joseph Rushton Wakeling via Digitalmars-d-announce

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.


Re: Release D 2.074.1

2017-06-03 Thread Seb via Digitalmars-d-announce
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.


Re: Release D 2.074.1

2017-06-03 Thread Joseph Rushton Wakeling via Digitalmars-d-announce

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.


Re: Release D 2.074.1

2017-06-03 Thread Seb via Digitalmars-d-announce
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


Re: Release D 2.074.1

2017-06-03 Thread Joseph Rushton Wakeling via Digitalmars-d-announce
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


Re: Release D 2.074.1

2017-06-03 Thread Joseph Rushton Wakeling via Digitalmars-d-announce

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.


Re: Release D 2.074.1

2017-06-03 Thread Joseph Rushton Wakeling via Digitalmars-d-announce

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.


Re: Release D 2.074.1

2017-06-02 Thread Jacob Carlborg via Digitalmars-d-announce

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_id=215151


--
/Jacob Carlborg


Re: Release D 2.074.1

2017-06-02 Thread Joseph Rushton Wakeling via Digitalmars-d-announce

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