On Wed, Oct 12, 2022 at 07:22:57PM +0000, Dennis via Digitalmars-d wrote:
> On Wednesday, 12 October 2022 at 19:04:26 UTC, H. S. Teoh wrote:
> > The current official release of dmd is 2.100.2, but when I build from the git repo, `dmd --version` says:
> 
> Some thinks that come to mind:
> - Is your repo up to date with dlang/dmd?

Just pulled from github just now.


> - Is the `dmd` command actually executing the dmd you built?

Yes.  I even `git clean -dfx` in the dmd repo and rebuilt, just to make sure.


> - Do you have a locally overridden VERSION file in the root?

The VERSION file says:

	v2.100.2

Hmm.


T

-- 
I see that you JS got Bach.

On Wed, Oct 12, 2022 at 04:31:20PM -0400, Steven Schveighoffer via Digitalmars-d wrote:
> On 10/12/22 3:04 PM, H. S. Teoh wrote:
> > The current official release of dmd is 2.100.2, but when I build from the git repo, `dmd --version` says:
> > 
> > 	DMD64 D Compiler v2.098.1-10051-g61d7d56a0
> > 	Copyright (C) 1999-2022 by The D Language Foundation, All Rights Reserved written by Walter Bright
> > 
> > Why is it still reporting 2.098.1?  Isn't that like several releases behind already?
[...]
> That looks like a git version tag + some commit.
> 
> When you pull the remote branch in, do you specify --tags? You may not be acquiring all the git tags into your local repo.
[...]

You mean it acquires the version number from git tags??  That explains a lot. :-D


T

-- 
Never criticize a man until you've walked a mile in his shoes. Then when you do criticize him, you'll be a mile away and he won't have his shoes.

On Wed, Oct 12, 2022 at 04:31:20PM -0400, Steven Schveighoffer via Digitalmars-d wrote: [...]
> When you pull the remote branch in, do you specify --tags? You may not be acquiring all the git tags into your local repo.
[...]

Re-pulled with --tags and rebuilt.  Now dmd reports:

	DMD64 D Compiler v2.100.2

	Copyright (C) 1999-2022 by The D Language Foundation, All Rights Reserved written by Walter Bright

Now *that* sounds more like it. :-D

Thanks for the tip. (Though I must say, it strikes me as a little odd to key the version number off git tags, which are fluid and arbitrarily-assigned, as opposed to actual source code that reflects the actual functionality behind a particular version number...)


T

-- 
What doesn't kill me makes me stranger.

On Wed, Oct 12, 2022 at 05:06:25PM -0400, Steven Schveighoffer via Digitalmars-d wrote:
> On 10/12/22 4:45 PM, H. S. Teoh wrote:
> 
> > Thanks for the tip. (Though I must say, it strikes me as a little odd to key the version number off git tags, which are fluid and arbitrarily-assigned, as opposed to actual source code that reflects the actual functionality behind a particular version number...)
> 
> The main benefit is if you build with a non-tagged version, you can know exactly which commit caused your abomination to exist.

Including the git commit hash in the version number is generally a good idea IMO.  But what strikes me as odd is keying the official release version number on a git tag -- to the point that even __VERSION__ reports 2098L in spite of the compiler being functionally already 2.100.2.  This leads to potentially "interesting" effects when this compiler is then used to compile code that checks __VERSION__ with static if...  (This makes the 2.100.2 compiler insist that it's 2.098, and even convince itself that it's 2.098, but functionally it's actually 2.100.2.)


> And also, git tags are somewhat fluid, but also pretty rigid, it takes a lot to delete them and update the server to the new one.
[...]

But when someone clones your repo and forgets to download the tags, you end up with confused compilers who think they're a different version from what they actually are. :-D


T

-- 
Just because you can, doesn't mean you should.

On Thu, Oct 13, 2022 at 03:52:57AM +0000, norm via Digitalmars-d wrote:
> On Wednesday, 12 October 2022 at 20:45:43 UTC, H. S. Teoh wrote:
[...]
> > Thanks for the tip. (Though I must say, it strikes me as a little odd to key the version number off git tags, which are fluid and arbitrarily-assigned, as opposed to actual source code that reflects the actual functionality behind a particular version number...)
[...]
> Using git tags is quite common in places where I've worked. CI/CD is configured to build a release with changelog and release note when it sees a semantic version tag arrive.
[...]
> This `v1.2.3-0-gabcd12345` clearly indicates the version, if it is actually a release build, and the commit hash, which for us we find most important.  One less dereference we have to do when bugs are reported.
[...]

It's not so much the usage of git tags for release versioning that I find odd.  It's the fact that dmd 2.100.2 insists that it's 2.098, sets `__VERSION__` to 2098L, and believes that it's 2.098, yet the state of code is clearly already 2.100.2 and the compiler will behave like a 2.100.2 compiler.

In my mind, the state of source code defines the meaning behind the version number, and therefore the version number ought to be encoded in the source code, so that the two are consistent.  This is particularly so in a D compiler where the version number returned by `__VERSION__` could cause semantic changes in downstream user code (due to static if, etc.).

Imagine the hypothetical case where 2.100.2 introduced a breaking syntax change for which user code has to be updated; a user project that wants to be compilable with both versions of the compiler would likely do something like:

	static if (__VERSION__ <= 2098L) {
		... // implement feature using 2.098 syntax
	} else {
		... // implement feature using 2.100.2 syntax
	}

In this case, since the compiler thinks it's 2.098, it will compile the first branch of the static if, but since it's actually a 2.100.2 compiler, it will fail to compile the code that's meant for 2.098. To add to the confusion, it claims that it's a 2.098 compiler, which will surely leave users *really* scratching their heads as to what exactly is going on. :-P


T

-- 
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- D. Knuth

On Wednesday, 12 October 2022 at 20:45:43 UTC, H. S. Teoh wrote:
>
> Thanks for the tip. (Though I must say, it strikes me as a little odd to key the version number off git tags, which are fluid and arbitrarily-assigned, as opposed to actual source code that reflects the actual functionality behind a particular version number...)

It seems you've had this issue before: https://www.digitalmars.com/d/archives/digitalmars/D/DMD_git_master_stuck_at_2.084_331087.html :D