https://issues.dlang.org/show_bug.cgi?id=15910

Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code@dawg.eu

--- Comment #1 from Martin Nowak <code@dawg.eu> ---
> For the second release in a row (2.070.0 followed by 2.071.0), dmd has been released with the VERSION file not updated to match the release version

That's not entirely correct b/c the downloadable packages contain the correct
VERSION file, it's only that the tagged git commits have an incorrect VERSION
file.
Now we could validate that the VERSION file contains the to be build tag, but
this will be a constant nuisance, e.g. deleting already created tags, changing
the VERSION from 2.071.0-b1 to 2.071.0-b2, retag, and build.
I'd instead suggest that any build script using the git repo or tags, should
get the VERSION from git or write the VERSION file when downloading a tar
bundle from github.
VERSION can also be set through make -f posix.mak VERSION=2.071.0.

--

https://issues.dlang.org/show_bug.cgi?id=15910

--- Comment #2 from Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> ---
> That's not entirely correct b/c the downloadable packages contain the correct VERSION file

Well, yes, that's really the point of concern -- there is a mismatch between
the downloadable packages (correct version) and the git-hosted source
(incorrect version), that shouldn't be there.

> Now we could validate that the VERSION file contains the to be build tag, but this will be a constant nuisance, e.g. deleting already created tags, changing the VERSION from 2.071.0-b1 to 2.071.0-b2, retag, and build.

I'm not sure I follow the concern here.  If there are multiple version tags on a single commit, isn't the norm to just take the highest version out of all of them?  And then compare to VERSION contents ... ?

> I'd instead suggest that any build script using the git repo or tags, should get the VERSION from git or write the VERSION file when downloading a tar bundle from github.

Yes, it makes sense that git tags might be the principal source of version information and that VERSION should derive from that.  Probably this could address both the issue described here and <https://issues.dlang.org/show_bug.cgi?id=12229> all in one go?

> VERSION can also be set through make -f posix.mak VERSION=2.071.0

Thanks, that's useful.

--

https://issues.dlang.org/show_bug.cgi?id=15910

--- Comment #3 from Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> ---
Unfortunately, the proposed workaround didn't work for me when I tried it.

If when trying to build phobos I use,

    make -f posix.mak VERSION=2.071

then I wind up with generated library files:

libphobos2.so -> libphobos2.so.0..
libphobos2.so.0. -> libphobos2.so.0..
libphobos2.so.0..
libphobos2.so.0..o

... when obviously I'd expect the names to be so.0.71.0 etc.

Tweaking to e.g. VERSION=2.071.0 makes no difference, it looks like phobos' build scripts just can't handle a custom VERSION override like this.

--

https://issues.dlang.org/show_bug.cgi?id=15910

John Colvin <john.loughran.colvin@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |john.loughran.colvin@gmail.
                   |                            |com

--- Comment #4 from John Colvin <john.loughran.colvin@gmail.com> ---
(In reply to Joseph Rushton Wakeling from comment #3)
> Unfortunately, the proposed workaround didn't work for me when I tried it.
> 
> If when trying to build phobos I use,
> 
>     make -f posix.mak VERSION=2.071
> 
> then I wind up with generated library files:
> 
> libphobos2.so -> libphobos2.so.0..
> libphobos2.so.0. -> libphobos2.so.0..
> libphobos2.so.0..
> libphobos2.so.0..o
> 
> ... when obviously I'd expect the names to be so.0.71.0 etc.
> 
> Tweaking to e.g. VERSION=2.071.0 makes no difference, it looks like phobos' build scripts just can't handle a custom VERSION override like this.

I think VERSION= expects a file, not a value

--

https://issues.dlang.org/show_bug.cgi?id=15910

--- Comment #5 from Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> ---
Note that with the DMD backend now open sourced, this is going to have a greater impact: unless it's addressed, every downstream packager will have to implement a manual workaround.  This isn't hard, but it is finnicky, and hence best avoided.

I don't want to advocate for any particular solution, but could we agree the following goals?

* any build from git source should reflect the version according to git tags, without needing to modify anything in the source tree

* any build from a tarball should reflect the version of the source used to generate that tarball, again without needing to modify anything in the source tree.

Does that sound reasonable?

--

https://issues.dlang.org/show_bug.cgi?id=15910

Seb <greensunny12@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |greensunny12@gmail.com

--- Comment #6 from Seb <greensunny12@gmail.com> ---
Since a few versions DMD use the statically stored VERSION

https://github.com/dlang/dmd/pull/6935 https://github.com/dlang/dmd/pull/6749

Did this solve your problem?

--

https://issues.dlang.org/show_bug.cgi?id=15910

Iain Buclaw <ibuclaw@gdcproject.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P4

--

https://issues.dlang.org/show_bug.cgi?id=15910

--- Comment #7 from dlangBugzillaToGithub <robert.schadek@posteo.de> ---
THIS ISSUE HAS BEEN MOVED TO GITHUB

https://github.com/dlang/installer/issues/658

DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB

--