Hi,
we are using a versioning schema like 1.22.0-ci.{height} in the version.json.
We develop ci-versions in the dev branch. When we switch to a release branch we manually change the prerelease tag to rc (1.22.0-rc.{height}). We would expect the height to start at 0 again in the release branch but it continues from the value it had in dev.
Reading the docs it seems to be by design that the prerelease-tag is not taken into account for height-resets. Is it possible to achieve our intended behaviour? Shouldn't the prerelease-tag be taken into account at least when you are not using height for the patch-part but for the prerelease-part (like in our case)?
Thanks
Tobias
Git height is calculated based on changes to the major.minor portion of the version only. This was designed back when version height always appeared as the 3rd integer (before we made its placement customizable).
I could perhaps see making this more flexible to allow for including the 3rd (or even 4th) integer of the version in that calculation when height is included elsewhere. But I would be concerned about resetting on prerelease tag changes since that would result in repeating of versions:
| SemVer | 3/4 integer version |
|--|--|
| 1.0.1-alpha | 1.0.1 |
| 1.0.2-alpha | 1.0.2 |
| 1.0.1-beta | 1.0.1 |
See how the first beta would collide with the first alpha? The integer-only version needs to be unique because this feeds into several version fields that only permit a.b.c.d versions such as assembly version, assembly file version, WinPE file version, etc.
OK. I think we wouldn't mind if special version attributes are not unique (as long as we have one detailed version attribute, like product version on the assembly). But that is just my opinion.
Anyway I appreciate if you could allow for including the 3rd integer when height is in the prerelease part.
Thanks!
Anyway I appreciate if you could allow for including the 3rd integer when height is in the prerelease part.
Sounds good. Just to clearly set expectations, across the many projects I contribute to, this is just one. It's not particularly close to the top of the priority list either. I would entertain a PR submitted by someone else, but I'd require it to be backward compatible (not arbitrarily changing versions of existing commits in repos that simply upgrade).