dmd git master version

[norm]

On Thursday, 13 October 2022 at 03:52:57 UTC, norm wrote:
> 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: [...]
>>> [...]
>> [...]
>>
>> 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 :)

I should point out too that github, gitlab, bitbucket et. al. 
have the protect tags feature and understand this approach. So a 
release tag is protected and not fluid, our script also easily do 
this too with a a simple regex. All other tags are fluid, and 
largely  irrelevant tbh we hardly use tags for anything but 
releases.

and we don't branch a release until we start patch releases, 
which of course branch at the  respective tag.