Allow for disabling the pre-release additions by a property value

[mockjv]

Use case(s)

Currently, at least from my understanding of the documentation and my personal tests, minver appends the pre-release identifiers whenever the current checkout is a different branch than where the version tag was applied. In complex branch workflows, this complicates the application of a version without pre-release and without using a history re-write such as a rebase. A simple potential solution to this could be a property to explicitly disable adding the pre-release identifiers by property, allowing CI/CD systems or project files to control this behavior.

Description

Add a new MinVerSkipPreRelease property, which when set to true would not append the pre-release information to the versions.

Alternatives

We could also possibly consider a list property that could contain a list of branches to consider as "release", such that when minver is processed on those particular branches then pre-release identifiers will not be added to the versions.

Otherwise, I've not seen any other method available to us within the documentation.

Additional context

I do plan to look into the changes necessary to introduce this feature and submit a PR as a result.

[adamralph]

@mockjv I'm not sure I follow. The entire idea of MinVer is that when you want to build and release a version of your software from a specific commit, you first tag that commit, and then build.

[mockjv]

So in our particular case a decision was made to utilize a modified GitHub Flow in combination with GitHub Actions to control the deployment states of a simple web service.

The following shows a rudimentary example of our modified GitHub flow. The idea being that by the time our merge hits main, the service has already been through acceptance and deployment (merges into staging and main are strictly controlled with branch protections and CODE_OWNERS). We can easily tag the commit set before merging into the appropriate branches that control final deployment, but that build now being on a different branch than where the tag was created the pre-release identifiers will be added. For this example our staged service would then have a version of 1.0.0-alpha.1.

So the thought here is that if within our CI/CD process we decide to set MinVerSkipPreRelease to true, and disable adding those values to the final version, we could override that particular behavior to produce:

1.0.0-1 for the build that was performed on staging after qa was merged.

And we accept in our case that the height will always be at least 1.

gitGraph
    commit
    branch staging
    branch qa
    branch fancy_feature
    commit
    checkout qa
    merge fancy_feature id: "deploy_qa" tag: "v1.0.0"
    checkout staging
    merge qa id: "deploy_staging"
    checkout main
    merge staging id: "service_live"

Loading

There are some other conditions that we've considered like having the deploy_to_staging GitHub Action triggered by version tags. However, the limitations of tag protection don't have the same verification process as a merge via PR, so controlling builds by merge/push are currently our preference.

Hopefully this clarifies the thought a little bit better.

[adamralph]

I would always advocate tagging to release, since that fits naturally with the design of MinVer.

However, I just realised that the feature you want already exists. 🙂

[mockjv]

@adamralph Ah, I didn't connect that MinVerIgnoreHeight also affected the pre-release identifiers. Maybe expanding upon that description would help make that clearer? Nevertheless, that does generally do what we wanted, so I'm happy to close.

Thank you so much for pointing me in the right direction though!