Do not include MinVerBuildMetadata in PackageVersion

[bording]

Use case(s)

It's useful to set MinVerBuildMetadata to get the build metadata into the assembly informational version. However, it is usually undesirable to have the build meta data added to the package version.

Description

Currently, the value assigned to MinVerBuildMetadata is included in MinVerVersion, which is used to set PackageVersion. That means that the build metadata forms part of the package version:

Package file name: LibGit2Sharp.0.27.0.nupkg

With this change, the build metadata is only included in the assembly informational version.

Alternatives

• A custom target to fix the PackageVersion property.
• Stop using MinVerBuildMetadata to get the value into the informational version, which is where I really want it

Additional context

This is a problem because when you upload a package to nuget.org, the build metadata is included in the version.

Sure, I can fix it with a custom target, but it's a pain to have do that. I can't see any real value in having the build metadata in there given how NuGet treats it, and I imagine that most people aren't going to want that in there, especially on a release package.

BTW, I hit this while in the process of releasing a new version of LibGit2Sharp. I just switched it over to MinVer this weekend.

[adamralph]

@bording thanks for raising this. I see the value. At one time I used MinVerBuildMetadata in my own packages but I didn't like that the build metadata was front and centre in the version displayed in NuGet so I stopped using it. It's handled slightly differently now, but it's still a bit noisy to look at:

When I designed the feature I didn't give any thought to suppressing the build metadata anywhere. Since it's included in SemVer 2.0, I thought I'd just leave it to flow through to where it ends up. But I do see the value in not including it in the package version by default, and only including it in the assembly informational version by default.

This isn't a bug though. The current behaviour is by design. So I think this issue should be reshaped as an enhancement. I can do that, unless you want to.

This would be a breaking change, but that's fine. The next version is already going to be a new major (5.0.0).

[bording]

This isn't a bug though. The current behaviour is by design. So I think this issue should be reshaped as an enhancement.

That statement seems to assume that a problem with a design can't be considered a bug, which I'm not sure I agree with! 😄

I can do that, unless you want to.

I don't feel strongly either way on this.

This would be a breaking change

Yes, I was assuming this would require a new major.

[adamralph]

@bording I've released this in 5.0.0-beta.1. Would you like to give it a try?

[bording]

@bording I've released this in 5.0.0-beta.1. Would you like to give it a try?

Looks like it's working as expected: libgit2/libgit2sharp@feb8344

[adamralph]

Excellent, thanks! I'll push out 5.0.0 shortly.