dotnet / Nerdbank.GitVersioning

Stamp your assemblies, packages and more with a unique version generated from a single, simple version.json file and include git commit IDs for non-official builds.
https://www.nuget.org/packages/Nerdbank.GitVersioning
MIT License
1.32k stars 165 forks source link

[Question] Using height only in branches that don't match publicReleaseRefSpec criteria #1018

Closed Cjewett closed 6 months ago

Cjewett commented 6 months ago

We have a version.json that looks like the below:

{
  "$schema": "https://raw.githubusercontent.com/dotnet/Nerdbank.GitVersioning/main/src/NerdBank.GitVersioning/version.schema.json",
  "version": "3.0",
  "versionHeightOffset": -1,
  "assemblyVersion": {
    "precision": "revision"
  },
  "publicReleaseRefSpec": [
    "^refs/heads/main$"
  ],
  "pathFilters": [ "." ]
}

It has been working great and we want to take release of packages one step forward beyond only releasing from main. We want to start releasing per branch as a next step. With the version.json's current state a branch that matches a Jira issue name (requirement by Jira) such as EAT-12345 will output a NuGet package version similar to 3.0.1-g75783efc96. This stays the same regardless of the # of commits on that branch though, so what we want to do is add the height to the version when not matching publicReleaseRefSpec. The version would end up looking like 3.0.1.42146-g75783efc96. We can do this easily by adding:

"nugetPackageVersion": {
  "precision": "revision"
}

That will add the height to both release and pre-release versions though. Is there a way to only include height if the branch does not match publicReleaseRefSpec?

Cjewett commented 6 months ago

Closing this since after looking through the docs and other issues it seems like this isn't a good use case. Think we can improve our internal process a little instead.