How can I apply the pre-release identifier even if my tag already pre-release?

[SKProCH]

I've have a nightly prelease identifier, it works fine if I has usual version tags (e,g, 1.1.1 becomes the 1.1.1.nightly.HEIGHT), but if I have the tag which already prerelease, such as v0.8.0-avalonia11dot1-1 it just appends the .HEIGHT to the version:

MinVer: Using { Commit: 27ce61b, Tag: 'v0.8.0-avalonia11', Version: 0.8.0-avalonia11, Height: 1 }.
MinVer: Calculated version 0.8.0-avalonia11.1.
0.8.0-avalonia11.1

I want, in this case it became an: 0.8.0-avalonia11.nightly.1 or something like that. Is this possible?

[adamralph]

@SKProCH "nightly" suggests that you have a scheduled job which builds artifacts and publishes them in some way. Bear in mind that the design philosophy around MinVer is "tag first". I.e. the first thing you do before you release (whether pre-release or not), is to tag the repo. The philosophy assumes that the auto-generated versions (i.e. those with only height added) are not being released, and are only used for ad-hoc internal testing, etc. Attempts to use those versions for any kind of release usually end up in conflict with the design philosophy in some way.

So, if I understand your use case correctly, I would remove the nightly default pre-release phase (or replace it with another desired default) and instead add a step at the beginning of the scheduled job to determine what the tag should be (even if you don't actually tag the current commit). And in doing that, your tag could even represent the scheduled nature of those releases by including a date.

For example (pseudo-code):

1. Run minver to get the version
2. Augment the version with your nightly identifiers, e.g. nightly.20240721
3. Set the MINVERVERSIONOVERIDE environment variable to the version (this effectively makes MinVer behave as if the current commit has this tag, but without having to actually calculate the version, so it's much faster)
4. (Optional) tag the current commit with the version and push the tag to the upstream repo
5. Proceed with the rest of the build and publish the artifacts

How you augment the version (step 2) is up to you. E.g. you could simply append your nightly identifiers:

• 0.7.0 (current commit is tagged) becomes 0.7.0-nightly.20240721
• 0.7.1-alpha.1 (current commit is not tagged) becomes 0.7.1-alpha.1-nightly.20240721
• 0.8.0-avalonia11 (current commit is tagged) becomes 0.8.0-avalonia11-nightly.20240721
• 0.8.0-avalonia11.1 (current commit is not tagged) becomes 0.8.0-avalonia11.1-nightly.20240721

The above versions are valid SemVer, but a nicer, subtle variant of that is to be smarted with the dots and dashes:

• 0.7.1-alpha.1 becomes 0.7.1-alpha.1.nightly.20240721
• 0.8.0-avalonia11 becomes 0.8.0-avalonia11.nightly.20240721
• 0.8.0-avalonia11.1 becomes 0.8.0-avalonia11.1.nightly.20240721

Another option is to inject your nightly identifiers into the start of the pre-release identifiers:

• 0.7.1-alpha.1 becomes 0.7.1-nightly.20240721.alpha.1
• 0.8.0-avalonia11 becomes 0.8.0-nightly.20240721.avalonia11
• 0.8.0-avalonia11.1 becomes 0.8.0-nightly.20240721.avalonia11.1

You could also avoid using minver and instead set something like a NIGHTLY env var which triggers a custom target to do all this, but that depends on how much appetite you have for doing work inside MSBuild XML rather than outside it.