Bug 17775 – dmd master __VERSION__ should match the major release that it will be for

Right now, it seems that the way that dmd version number is handled is that it matches the current major release and gets bumped when another major release is made. So, if 2.075 is the current major release, then dmd --version with dmd master prints something like DMD64 D Compiler DMD64 D Compiler v2.075.0-336-g12fa5f06c and __VERSION__ is 2075. The main problem that I see with this is that if a change is made in master, and a project wants to / needs to version code differently based on whether it's building with master or something older, there's no way to do it, because __VERSION__ is the same for both, whereas if master had the version number of the release that will come from it next rather than the release that came from it last, then no such problem exists. And since minor releases are released from the stable branch rather than master, having master be a higher version number than what the minor release will have shouldn't matter, and the higher version that master does have will match what the next major release is. So, it can just be bumped after the new branch for the next release is made rather than being bumped right before it's made, which seems to be how it works now. What we have right now seems to manage to make sure that the releases have the right version, but it doesn't play well at all for using __VERSION__ when you need to differentiate from master.

This was changed in https://github.com/dlang/dmd/pull/6935.

(In reply to ZombineDev from comment #1) > This was changed in https://github.com/dlang/dmd/pull/6935. Drat. Well, I can't say that I understand how all of that stuff with the release process works and how dmd knows what its version is, but the fact that __VERSION__ for master is not a higher number than the latest release is a definite problem for any code that needs to do something differently with master due to upcoming changes or whatnot. I ran into this problem recently when making some changes to vibe.d.

I agree that it's quite annoying. Perhaps we can add another predefined constant like __IS_DEV_VERSION__ which would evaluate to true iff the ddmd.globals.global._version has any non-digit character after the minor version (or simply if its length is > 8)?

(In reply to ZombineDev from comment #3) > I agree that it's quite annoying. Perhaps we can add another predefined > constant like __IS_DEV_VERSION__ which would evaluate to true iff the > ddmd.globals.global._version has any non-digit character after the minor > version (or simply if its length is > 8)? The problem with that is that then you're testing specifically for dmd master not that the code is newer than a particular release. If a change is made in dmd master that's going to go in the next release, and __VERSION__ in dmd master is the version of the next release, then you can check __VERSION__, and the code will continue to do the right thing once dmd master becomes the next release, but if you're checking __IS_DEV_VERSION__, then that doesn't work. You'd have to change your code to use __VERSION__ once the next release is out. While I can understand that with however the version numbers are currently being generated, there may be issues having __VERSION__ be the number of the next release in master rather than the current reelase, I really think that if you consider what __VERSION__ is for, it really doesn't make sense for it to give the same number as the most recent release for master. That destroys its ability to be used for what it's designed for when dmd master is involved.

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/19309 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB