Git2SemVer.MSBuild setup

[RevZero]

According to the documentation I just added the NoeticTools.Git2SemVer.MSBuild package to my project.
By not providing any specific configuration, I was expecting the latest tag to be used for version generation.

I have the Tag "3.0.0" on "main" branch, but the generated version output looks like this:

1>  Executing Git2SemVer.MSBuild task to generate version. (Tue, 25 Feb 2025 16:09:30 GMT)
1>  Detected host: 'Uncontrolled'
1>  Using 'Uncontrolled' host. Build ID: DEV-PC-01.7
1>  Using git path: 'git'
1>  Git version (in Semver format) is '2.47.1+windows.2'
1>  Bumping build number to 8.
1>  Current branch: main
1>  Finding git path segments to last releases.
1>  Found 1 segments (0ms)
1>    Segment #   Commits (count)      Bumps   Release
1>    Segment 1   b06b60ded40427542da26774141e51259164a8f3 -> 1f01bb3d344081ad02a997ff2e85586fd169f4fc   (22)   ---    0.1.0
1>  Building git paths to last releases from segments.
1>  Found 1 paths.
1>  Path #   Segments (count)            Bumps    Ver from/to
1>  Path 1   1                     (22)   ---    none -> 0.1.0
1>  Running default version builder.
1>    Version: 0.1.0-InitialDev.DEV-PC-01.8
1>    Informational version: 0.1.0-InitialDev.DEV-PC-01.8+main.b06b60ded40427542da26774141e51259164a8f3

Is there any additional setup required for this to work as desired?

[RobSmyth]

Hi @RevZero,

Sorry for my slow response. The default behavior is to look for a release tag with the format vn.n.n so if you add a tag v3.0.0 I expect it will work.

Having a glance at the documentation I do not think I have documented that. At least I cannot immediately see it. I will raise a bug for that.

Let me know if that fixes the problem. Thanks for asking.

[RobSmyth]

Created issue #37

[RobSmyth]

Documentation updated https://noetictools.github.io/Git2SemVer.MSBuild/Usage/ReleaseVersionTagging.html. Links added in getting started and default versioning topics.

@RevZero - If you can, a quick review would be great.

[RevZero]

Using "v" prefix works. Looking at the documentation, its still not clear to me, if/how this can be configured (to work without prefix).

The library currently does not support pre-release identifiers like v1.2.3-alpha correct? At least it did not work when I tried it. This is an issue if you intend to release nuget-packages, because "v1.2.3-alpha" and "v1.2.3" would both result in the same nuget package name (using "pack"). Just pointing this out.

[RobSmyth]

Excellent, glad it works. I too had thought that it was configurable but it is not. I think I mislead you.

Yes it does support alpha and beta builds and automatically versions nuget packages. See the examples link below and select each tab.

Quick summary:

• If alpha or beta depends on the branch name. See maturity identifiers link below.
• Version metadata depending if your building on a dev box (uncontrolled) or a build system like TeamCity. Can be overriden using MSBuild properties.

See:

• maturity identifiers.
• Examples
• MSBuild properties

[RobSmyth]

Let me know if you feel it would be useful to configure the release version tag prefix "v" or raise a feature request.

[RobSmyth]

@RevZero,

How has it worked out for you? By now I expect it is working or you have moved on to another solution. I'm interested in getting your feedback.

[RevZero]

Hi, thanks for the feedback. I tried a few other solutions and ended up with https://github.com/lord-executor/Larcanum.GitInfo for my current project, its very lightweight and derives the version from the git tag as I expected without additional configuration.

I also took a look at https://github.com/devlooped/GitInfo. Its nice, but uses https://github.com/devlooped#sponsorlink, which I found annoying and it has a lot of dependencies.

Essentially, I had two "issues" with you solution:

• The hard "v" prefix requirement. This is not a big thing, but it breaks consistency when you used non-prefixed version numbers in an existing repository so far.
• I just couldn't get the pre-release identifier to work. A tag like "1.0.0-alpha" would just end up as 1.0.0 and thus also build the nuget package as "packagename-1.0.0" instead of "packagename-1.0.0-alpha".

Maybe I just failed to find the relevant info in the docs.

[RobSmyth]

Thanks @RevZero,

That is great feedback. I need to improve documentation and make the prefix configurable.