PreRelease overrides keeps adding ".0"

[iampluque]

My question is about that guy in bold: 1.0.1-PR .0 .1+test

Major: 1
Minor: 0
Patch: 1
Prerelease: PR
Who the heck are you!?: 0
Height: 1
metadata: test

Is there a reason why if I use the defaultPreRelease override it keep adding the .0 at the end of my override, as opposed of what's written in the FAQ: https://github.com/adamralph/minver#can-i-change-the-default-pre-release-phase-from-alpha-to-something-else

I know the technical reason, it's hardcoded that way here:

minver/MinVer.Lib/Version.cs

Line 19 in 38b456c

public Version(string defaultPreReleasePhase) : this(0, 0, 0, new List<string> { defaultPreReleasePhase, "0" }, 0, null) { }

But is there another reason?

[adamralph]

Hi, please read https://github.com/adamralph/minver#how-it-works — it's all explained there.

[iampluque]

Default pre-release identifiers are added. The default pre-release phase is "alpha", but this can be customised.

I read it and it still not explain the "0" behavior ... it says alpha, not alpha.0. Can you be more specific?

[adamralph]

The 0 is the pre-release "number". That is, you don't want to be restricted to a single pre-release, since it's likely you will want a 1st pre-release (1.0.1.PR.1), a 2nd pre-release (1.0.1.PR.2) etc. The "0th" pre-release is not one that you will release. It's just a way of versioning the interim builds between an RTM and your next pre-release.

E.g. your commits might be versioned as follows:

• 0.0.0.PR.0 (root commit)
• 0.0.0.PR.0.1
• 0.0.0.PR.0.2
• 1.0.0.PR.1 (tagged and released)
• 1.0.0.PR.1.1
• 1.0.0.PR.1.2
• 1.0.0.PR.2 (tagged and released)
• 1.0.0.PR.2.1
• 1.0.0.PR.2.2
• 1.0.0 (tagged and released)
• 1.0.1.PR.0.1 <-- this is the version you are currently seeing
• 1.0.1.PR.0.2
• 1.0.1.PR.1 (tagged and released)
• 1.0.1.PR.1.1
• 1.0.1.PR.1.2
• 1.0.1.PR.2 (tagged and released)
• 1.0.1.PR.2.1
• 1.0.1.PR.2.2
• 1.0.1 (tagged and released)
• ...

Side note: you may want to consider using something other than "PR" as your pre-release phase. It's easily confused with "pull request". When I first saw it, I thought that's what it meant.

[iampluque]

💯 agree on side note! :')

Oh I just understood by re-reading you how-to's that you consider PR (in this case) as a pre-release phase. That is the important part that I didn't understood on your way to implement the pre-release identifier.

As 1.0.0.PR.1 (tagged and released) is a manual tag, I wasn't understanding why you wouldn't just append the height after the pre-release identifier (PR I though in this case) .... now it's all clear 👍

Thanks! Happy holidays!

[adamralph]

Great, thanks! You too!

[lonix1]

it says alpha, not alpha.0

I was also confused by this, and the docs do not explain the concept of "phase".

When I read the above explanation - which due to the example format, is extremely helpful - it all made sense. It would be good for future readers if it were incorporated somehow into the docs.

Thanks for the excellent example.

[rafntor]

Forget it - I tried the beta and it does it just like that , so thanks ! 🚀

[rafntor]

This may be a corner-case ; but I would expect the commandline-supplied prerelase to take precence , instead it keeps the tagged prerelease-name. Is that intentional?

[adamralph]

@rafntor yes, it is intentional. Please see How it works.

[rafntor]

Yes I can see it matches the documentation. There is different handling if the preceding tag is an RTM-tag or Non-RTM-tag, both add height but only RTM-tags considers the supplied pre-release name. I would have liked if the argument applied equally to both, but I suppose it is a matter of choice ;-)

[adamralph]

only RTM-tags considers the supplied pre-release name

That's why they are called the default pre-release identifiers. They are the defaults, to be used when the last tag doesn't have any pre-release identifiers (i.e. it's an RTM tag).

If you want to publish a version of your software with MinVer, you should tag it. Then you have complete control over the version. I would advise using the versions with height for anything other than internal troubleshooting (e.g. bisecting to isolate bug introduction, etc.).