Incorrect bump version

[tiagoporto]

Thanks for the amazing lib.

I've created a workflow with release-it that mixes pre-release and official release and I found a bug in the default behavior.

release-it is not bumped correctly pre-releases. As you can see in the examples below.

I've used standard-version lib to compare.

Check this test:

release-it	standard-version

As you can see, release-it jumps from official release 1.0.0 to 2.0.1, on the other hand, standard-version does as expected.

Version

  "devDependencies": {
    "@release-it/conventional-changelog": "5.1.1",
    "release-it": "15.6.0"
  },

Config

{
  "git": {
    "commitMessage": "chore(release): ${version}",
    "push": false
  },
  "github": {
    "release": false
  },
  "npm": {
    "publish": false
  },
  "gitlab": {
    "release": false
  },
  "plugins": {
    "@release-it/conventional-changelog": {
      "preset": "conventionalcommits",
      "strictSemVer": true,
      "context": {
        "linkCompare": true
      },
      "infile": "CHANGELOG.md"
    }
  }
}

I have used only the commands :

• release-it --ci for official release
• release-it --ci --preRelease=alpha for pre-release

Similar command in standard-version

• standard-version for official release
• standard-version --prerelease alpha for pre-release

[webpro]

From what I see in the release-it screenshot, all is as expected/intended.

The difference is strictSemVer, sounds like you don't want to use this option?

[tiagoporto]

Hello @webpro, thank you for answering.
I did a test without strictSemVer, as you can see in the screenshots it fixed the previous behavior, but introduced another bug.

Check this test:

release-it	standard-version

release-it jumps incorrectly from version 2.0.0 to 2.0.1. Correct version should be 2.1.0
Tag 2.0.1-alpha.1 is not correct and should be 2.1.0-alpha.0

I think that strictSemVer should be the default behavior, and should follow the same standart-version implementation, otherwise this is not following the correct semver bumping.

Config

{
  "git": {
    "commitMessage": "chore(release): ${version}",
    "push": false
  },
  "github": {
    "release": false
  },
  "npm": {
    "publish": false
  },
  "gitlab": {
    "release": false
  },
  "plugins": {
    "@release-it/conventional-changelog": {
      "preset": "conventionalcommits",
      "context": {
        "linkCompare": true
      },
      "infile": "CHANGELOG.md"
    }
  }
}

[tiagoporto]

Hi @webpro, wdyt is the proposition make sense?

[webpro]

Without --strictSemVer and with --preRelease=alpha it indeed keeps bumping within the alpha.n range, this is intentional.

I will consider to make strictSemVer the default in the next major release.

[tiagoporto]

I will consider to make strictSemVer the default in the next major release.

Cool!!! Are you considering making strictSemVer following bump version as standard-version does?

Otherwise, this first reported bug still exists. -> #58 (comment).

[webpro]

Still not sure whether there's a bug or I don't understand correctly. What am I missing?

• Without --strictSemVer and with --preRelease=alpha it indeed keeps bumping within the alpha.n range, this is intentional.
• With --strictSemVer it works according to semver rules:

conventional-changelog/test.js

Lines 192 to 214 in ff9f1aa

	test('should follow strict semver (pre-release continuation)', async t => {
	setup();
	sh.exec(`git tag 1.1.0-alpha.0`);
	add('feat', 'baz');
	const [config, container] = getOptions({ preset, strictSemVer: true });
	config.preRelease = 'alpha';
	const { version } = await runTasks(config, container);
	assert.equal(version, '1.2.0-alpha.0');
	});
	test('should follow strict semver (pre-release continuation, conventionalcommits)', async t => {
	setup();
	sh.exec(`git tag 2.0.1-alpha.0`);
	sh.ShellString('file').toEnd('file');
	sh.exec(`git add file`);
	sh.exec(`git commit -m "feat: new feature"`);
	const [config, container] = getOptions({ preset: 'conventionalcommits', strictSemVer: true });
	config.preRelease = 'alpha';
	const { version } = await runTasks(config, container);
	assert.equal(version, '2.1.0-alpha.0');
	});

[webpro]

Maybe the confusion is about the following. Using the node-semver package here:

$ semver -i prepatch --preid alpha 2.0.0-alpha.0
2.0.1-alpha.0

$ semver -i prerelease --preid alpha 2.0.0-alpha.0
2.0.0-alpha.1

When the recommended bump from conventional-changelog is patch, then this plugin will use prepatch to bump.

Do you have a resource where it states this should be prerelease bump? And how to decide whether it should be prerelease or pre[patch|minor|major]?

[tiagoporto]

Hello again, thank you for answering.
I don't know what is the issue with node-semver, I guess is something internal right?

About the test.

Let me try to help you with a test that is going to replicate the issue.

Test case:

• Current version should be 2.0.0-alpha.0
• strictSemVer enabled
• Create a fix commit
• Run release-it --ci --preRelease=alpha
• Expected version should be 2.0.0-alpha.1 (Why? Because the official version 2.0.0 was not published yet, 2.0.0-alpha.0 means that the next version always will be 2.0.0).

If you run release-it --ci after this example the expected version should be 2.0.0, and not 2.0.1(current implementation).

[tiagoporto]

Do you have a resource where it states this should be prerelease bump? And how to decide whether it should be prerelease or pre[patch|minor|major]?

I don't have to decide, I expect that the lib take the correct decision for me.

I have 2 workflows, one for an official release and another for a pre-release.

Official release workflow runs release-it --ci
The pre-release run standard-version --prerelease alpha

This is why I found the bug, I had experience with standard-version, which bumps correctly, and after some versions using release-it I've noticed that this lib was messing up with the version.

[tiagoporto]

@webpro
I've opened a PR with the broken test https://github.com/release-it/conventional-changelog/pull/60/files I've mentioned.
I hope this can help understand.

[tiagoporto]

Hi @webpro, now is clear for you?

[webpro]

I don't know what is the issue with node-semver, I guess is something internal right?

This is the Node.js implementation of semver, node-semver and the semver spec are my main references.

(Why? Because the official version 2.0.0 was not published yet, 2.0.0-alpha.0 means that the next version always will be 2.0.0).

I understand when coming from another tool that behaves differently it may be perceived as incorrect behavior or a bug. But apparently we're both not sure if there are formal rules or any kind of formalization, right?

I'm happy to reconsider and change the behavior in this plugin, but not without any backup or explanation as to where the change comes from.

[webpro]

Closing this, release-it + plugins (and its dependencies) follow node-semver.