Add support for pre-release labels

[eduherminio]

When setting a specific version, it would be awesome to be able to:

• Set a semantic version with pre-release labels (-alpha, etc.).
• Override an existing version that has a pre-release label.

For major, minor and patch behavior could remain the same as it is, not being able to run them successfully if the existing version has a pre-release label.

[nover]

@eduherminio
I like the overall concept of your suggestion, however

Override an existing version that has a pre-release label.

I'm not sure whether I like that - to me, git tags (which the tool produces as well) are immutable, so replacing a tag is a no go in my book. We could however make it an opt-in / warn the user appropriately before allowing it.

Another approach we could take is looking at how yarn / npm is doing it given that this tool takes inspiration from them:
https://classic.yarnpkg.com/en/docs/cli/version/#toc-commands

Basically there's premajor, preminor, prepatch and then the prerelease toggle to just "increment the pre-release version".

Let me know what you think.

[eduherminio]

Hi @nover.

I didn't express myself correctly. By override I meant be able to replace.
That is, it you currently set a project version to 0.1.0-alpha, the tool is unable to modify it.
If you add pre-release labels support, it has to be added to both the version that is going to be applied and the existing version.

Messing around with git tags is definitely a no-go 😆 .

Also, I like the idea of premajor, preminor and prepatch with the <pre-identifier> as a complement to the labels support in specific version, that would complete my suggested feature

[nover]

Well that clarifies it for me - great that we are in the same boat! :D

I will proceed with the yarn inspired way of handling pre-releases and "snapping back out of them" - which is correct - that is not handled by the CLI at this point.

I have a quite busy work-schedule these days, but I will do what I can to squeeze it in.

[eduherminio]

If you can release the already implemented functionality, I'd be happy to beta-test it.

[nover]

Thanks, I seem to remember that I had some problem with the code that I wanted to debug.

I'll get back to you later today!

[nover]

@eduherminio pre-major 2.0.0-0 is now rolling (made with the cli tool!)

[nover]

Scratch that - there is some problem with publishing the package to nuget.

[nover]

@eduherminio Managed to get a version out to nuget now! v2.0.0-3, you should be able to install it by

$ dotnet tool uninstall -g dotnet-version-cli  
$ dotnet tool install -g dotnet-version-cli --version "2.0.0-*"                                                                                                                                               

I'm hitting an interesting nightmare with nuget and SemVer 2.0.
If I release packages like 2.0.0-3 it does not believe it's SemVer 2.0 so it validates against SemVer 1.0 rules, and becomes invalid.
https://docs.microsoft.com/en-us/nuget/concepts/package-versioning#pre-release-versions
So for this particular release I included build-meta to force nuget to recognize the version number as semver 2.0.

I will be looking at workarounds for this.
The release of dotnet version cli boiled down to the command:

$ dotnet version -f src/dotnet-version.csproj --build-meta `git rev-parse --short HEAD` prerelease 

To bump the prerelease counter. To enter pre-release mode you can use one of the prepatch, preminor, premajor switches :)

[eduherminio]

Really appreciate it, I'll test it with my pipelines and get back to you sooner than later.

Regarding your small nightmare, I'd guess it's caused by your pre-release label starting with a number. I've never experienced such problems with tags like alpha-n, it may be worth a try to ensure it's not that.

[nover]

Really appreciate it, I'll test it with my pipelines and get back to you sooner than later.

Great thanks!

.. pre-release label starting with a number...

Yes it's definitely that - however 2.0.0-1 is valid SemVer 2.0 (and how yarn does it).
According to NuGet docs I either have to include build-meta or have a semver 2 dependency version constraint in the nuspec file, so I'm leaning towards the latter.