Support for Gitflow workflows

[heaths]

We use a gitflow workflow where the master branch is a release branch while a develop branch exists as a stabilization branch. Topic branches merge into the develop branch from which we release pre-releases for testing. Upon successful testing, we merge develop into master to create a release.

To date, NBGV has been mostly supporting this flow through my misunderstanding of "non-public releases" to mean "pre-releases". That is, with the default settings for cloud builds to include the commit ID, we do get something like "1.2.3+abcd1234" for topic and develop branches, while our master branch might build a 1.2.4 (we create a merge commit when merging from develop to release; otherwise, I realize this breaks semver). We then merge from master to develop (--ff-only) to pick up the merge commit and development continues with topic branches off develop.

The only thing not ideal with NBGV is that the build number uses build metadata (the default for cloud builds). We'd like to have NBGV set the prer-elease metadata instead (with or without the leading "g" - probably without given you recently dropped it from all but nupkg packages) to the pre-release format like it does for nupkgs.

Realizing this would be a breaking change, I propose opting into it by adding a third enum value to #/cloudBuild/buildNumer/includeCommitId/where like "preReleaseForNonPublicReleases" or something suitably verbose (lacking the ability to document enum values in JSON schema).

All this would really change is instead of 1.2.3+abcd1234 our cloud build number would be 1.2.3-abcd1234. And in our case, this build number then easily carries through our build to release pipelines (Azure Pipelines) without having to persist across pipelines otherwise.

[benmccallum]

Jumping on the gitflow workflow topic...

I was just playing around with versions generated too if I branched off develop to create a feature/x or bugfix/y and they'll get the same version (until another commit) as develop. Looking at the docs here, it mentions how git hashes are useful in differing main and say a hotfix branch off main (as main is public release and hotfix isn't so will get the prerelease tagging), but that doesn't work when you're branching off a non-public release, which can also happen if people are tacking say refining a release with their own offshoot branches.

For us, we're putting our branch names (truncated) into the build info though for searchability/visibility of packages (and Octopus Deploy Releases), so we will get uniqueness that way, and then the only issue would be a manual re-run of a build on the same commit and branch.

This stuff certainly ain't easy :P

[benmccallum]

I've since realised I might be missing the point?

For a non-public release build, perhaps that's what you want, a reproducible version. Since it's not public, what you do with that beyond the build part is up to you, i.e. overwrite an Octopus Deploy release or just discard it. I'm hopeful in my case this won't happen anyway, and it's not the worst thing in the world to need to add a commit to get a fresh build through CI/CD. Not really any slower than hitting the replay build button in some UI somewhere.