height not incremented as expected (or maybe my expectations are wrong)

This PR https://github.com/ServiceComposer/ServiceComposer.AspNetCore/pull/18 correctly generates a package versioned as *-PR.18.alpha.0.*, so far so good. I was expecting the height to increase with each commit, so *-PR.18.alpha.0.0, *-PR.18.alpha.0.1, *-PR.18.alpha.0.etc.., and if my memory works correctly this was the behavior I was observing. First question:

Is my expectation correct?

If this is the case. Due to reasons I force pushed on the PR, clearly visible on GitHub. Since then it seems that on the PR the MinVer generated version is stuck at *-PR.18.alpha.0.2, as if the height from the last tag is always 2.

Full build history is available here: https://ci.appveyor.com/project/ServiceComposer/servicecomposer-aspnetcore/history

Am I doing something wrong?

[mauroservienti]

Thanks @adamralph. That’s fine, I like it. Closing this as solved.

[adamralph]

@mauroservienti yes, this is the expected behaviour. I suspect GitVersion does some kind of branch-based logic, and anything of that sort is deliberately avoided in MinVer.

Bear in mind that even if this logic exists, during the lifetime of a PR, the same height could be produced from two different builds. E.g. I could push one commit and build height 1, push another commit and build height 2, and then squash the commits and force push and build height 1 again. For that reason, I don’t think it’s a good idea to push packages to a feed with this logic in place. It would be better to embed the build number in the version somehow, and that would work with MinVer today. For example: https://github.com/ServiceComposer/ServiceComposer.AspNetCore/pull/22