[Issue 15910] Prevent mismatch of VERSION information in dmd releases

[d-bugmail--- via Digitalmars-d-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

   Priority|P1  |P4

--

[Issue 15910] Prevent mismatch of VERSION information in dmd releases

[d-bugmail--- via Digitalmars-d-bugs]

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

Seb  changed:

   What|Removed |Added

 CC||greensunn...@gmail.com

--- Comment #6 from Seb  ---
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?

--

[Issue 15910] Prevent mismatch of VERSION information in dmd releases

[via Digitalmars-d-bugs]

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

--- Comment #5 from Joseph Rushton Wakeling  ---
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?

--

[Issue 15910] Prevent mismatch of VERSION information in dmd releases

[via Digitalmars-d-bugs]

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

John Colvin  changed:

   What|Removed |Added

 CC||john.loughran.colvin@gmail.
   ||com

--- Comment #4 from John Colvin  ---
(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

--

[Issue 15910] Prevent mismatch of VERSION information in dmd releases

[via Digitalmars-d-bugs]

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

--- Comment #3 from Joseph Rushton Wakeling  ---
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.

--

[Issue 15910] Prevent mismatch of VERSION information in dmd releases

[via Digitalmars-d-bugs]

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

--- Comment #2 from Joseph Rushton Wakeling  ---
> 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
 all in one go?

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

Thanks, that's useful.

--

[Issue 15910] Prevent mismatch of VERSION information in dmd releases

[via Digitalmars-d-bugs]

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

Martin Nowak  changed:

   What|Removed |Added

 CC||c...@dawg.eu

--- Comment #1 from Martin Nowak  ---
> 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.

--