Prerelease NuGet version when squashing commits in Merge Request

[varasies]

Is there a strategy for calculating the NuGet version on merge request builds that will have its commits squashed when merging to main.

Scenario:

• Initial Version 1.1
• Feature Branch has 10 commits

In this scenario the MR builds will create prerelease NuGet packages with version 1.1.12-sha for testing. Once the MR is complete a release NuGet package with version 1.1.3 would be built from the master branch which would appear older than the prerelease package version.

A workaround for this would be to not squish the merge request but that would make rolling the entire merge request back more complicated if needed.

[AArnott]

Reverting a merged pull request isn't hard. git revert <merge-commit> -m 1 does it with just one commit.

I suppose we could have a setting somewhere that tells NB.GV to consider PR builds as just +1 of the target branch. Technically that's possible.

But why are you pushing PR builds packages to a feed with CI build packages such that you might compare their versions anyway? Also, the reason we add the -sha is because linear versioning doesn't work for non-publicReleaseRefSpec branches and so any version with a -commitsha on the end of it shouldn't be assumed to be newer/older than another version anyway, regardless of whether you squash or merge your PRs.

[varasies]

We push the prerelease NuGet packages to a local GitLab feed to test the changes to downstream projects. Ideally we would create unit tests instead but sometimes its easier to test in an actual implementation. Additionally pushing the NuGet packages makes it easier for the MR reviewers to test the changes.