dmd git master version

[norm]

On Wednesday, 12 October 2022 at 20:45:43 UTC, H. S. Teoh wrote:
> 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

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.

To create a release pack we simlpy run:
```
$ git tag -a vX.Y.Z -m "Tag release X.Y.Z" && git push origin 
--tags
```

To get the release information you just

```
$ git describe --long --dirty --match "v*.*.*"
v1.2.3-0-gabcd12345
```

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.

But we might be oddballs I guess, we refuse to use merge commits 
and insist on a linear history :)