--pre-release does not work when using custom configuration

[LouisRoselli]

The "--pre-release" option does not work correctly when using a custom configuration that has section types defined that aren't "fix" or "feat". "--pre-release" only works for "fix" and "feat". When using other custom defined types normally (NOT using --pre-release), will change the revision number...which is fine for now. Hopefully we can in the future be able to specify in the config if this is a minor or revision change for a specific type. If you have a commit mix of "fix/feat" and your custom type, it works. It just doesn't work if the custom type is the only commit. See examples below.

Project version used for all examples: "3.0.0"

Example Config for ".versionize":

{
  "changelog": {
    "header": "Version Release Notes",
    "sections": [
        {
            "type": "feat",
            "section": "✨ Features",
            "hidden": false
        },
        {
            "type": "fix",
            "section": "🐛 Bug Fixes",
            "hidden": false
        },
        {
            "type": "ci",
            "section": "👷‍ Continuous Integration",
            "hidden": false
        }
    ]
  }
}

Example using --pre-release (Does NOT Work):

git commit -a -m "ci: performance improvements"
versionize --pre-release "alpha"

Semantic versioning conflict: the next version 3.0.0-alpha.0 would be lower than the current version 3.0.0. This can be caused by using a wrong pre-release label or release as version

Example not using --pre-release (WORKS):

git commit -a -m "ci: performance improvements"
versionize

√ bumping version from 3.0.0 to 3.0.1 in projects
√ updated CHANGELOG.md
√ committed changes in projects and CHANGELOG.md
√ tagged release as 3.0.1

Example using --pre-release (WORKS):

git commit -a -m "ci: performance improvements"
git commit -a -m "fix: Main page wouldn't load"
versionize --pre-release "alpha"

√ bumping version from 3.0.0 to 3.0.1-alpha.0 in projects
√ updated CHANGELOG.md
√ committed changes in projects and CHANGELOG.md
√ tagged release as 3.0.1-alpha.0

[cabauman]

Hey @LouisRoselli, thanks for reporting. We'll look into a fix.

[LouisRoselli]

@cabauman, I appreciate the fast turn around on this, but the issue is still not fixed.

When running the following commands, I still get the same error in versionize 1.19.1:

versionize --ignore-insignificant-commits --pre-release "alpha"

OR

versionize --pre-release "alpha"

Result:

Semantic versioning conflict: the next version 1.0.0-alpha.0 would be lower than the current version 1.0.0. This can be caused by using a wrong pre-release label or release as version

See this sample repo as example: https://github.com/LouisRoselli/Versionize-Test

[cabauman]

Alright, I'll take another look. The snippet that uses ignore-insignificant-commits is expected to fail, but not the other one.

[cabauman]

There are no tags in the repo you shared but I assume you have a v1.0.0 tag locally on that release commit?

[LouisRoselli]

@cabauman sorry about that. I pushed the tags, and yes it's v1.0.0

[cabauman]

Well, that's odd. I got the correct result.

[LouisRoselli]

@cabauman I figured it out. A total rookie mistake on my part. It turns out I had Versionize installed globally with the --global option in "dotnet tools", and also locally by specifying it in the manifest file in the repo. The local version was on the newest, but the global installed on my machine was on an older version.

Sorry for the confusion, but this is working as expected. Thank You!!!!

[cabauman]

Awesome! Thanks again for the bug report and the update. We didn't have a test case for that scenario, but we do now.