Bug 15910 – Prevent mismatch of VERSION information in dmd releases

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: http://forum.dlang.org/post/[email protected] http://forum.dlang.org/post/[email protected] Among the consequences are that anyone building directly from source will end up with a wrong libdruntime library filename. The fact that this is a recurring problem suggests that the release procedure should be revised to make this impossible. A factor here may be that the release script overwrites the VERSION file, meaning that mismatches between git tags and the VERSION file will be hidden: https://github.com/D-Programming-Language/dmd/pull/5382#issuecomment-177545916 https://github.com/D-Programming-Language/installer/blob/67480ddd9a75170fe359a823225dfd60ca5027fd/create_dmd_release/build_all.d#L436-L446 Assuming that the VERSION file is still desired for e.g. users building from tarballs instead of git clones, this suggests that perhaps the release script should validate and require matching VERSION information instead of overwriting the file ... ?

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

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

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.

(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

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?

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?

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