Renovate violating v0 semver semantics

[trevor-scheer]

How are you running Renovate?

WhiteSource Renovate hosted app on github.com

Was this something which used to work for you, and then stopped?

I never saw this working

Describe the bug

Reproduction repo: https://github.com/trevor-scheer/renovate-reproduction
Violating PR: trevor-scheer/renovate-reproduction#2

At Apollo, we use the following package rule for grouping patch and minor updates into one PR.

{
  groupName: "all non-major dependencies",
  matchUpdateTypes: ["patch", "minor"],
  groupSlug: "all-npm-minor-patch",
  matchManagers: [ "npm" ],
}

This package rule is unexpectedly including a package whose version is going from ^0.2.3 to ^0.3.0. This update is generally treated as a major version bump while packages are in the version 0.y.z range. As such, I don't think it should be included by this package rule.

Here's a snippet using the semver package for demonstration:

const {satisfies} = require('semver');
console.log(satisfies('0.3.0', '^0.2.3')); // false
console.log(satisfies('0.3.0', '~0.2.3')); // false
console.log(satisfies('0.2.4', '^0.2.3')); // true
console.log(satisfies('0.2.4', '~0.2.3')); // true

Relevant debug logs

Logs

DEBUG: Using group branchName template
DEBUG: Dependency @apollo/core-schema is part of group all non-major dependencies
DEBUG: 1 flattened updates found: @apollo/core-schema
DEBUG: Returning 1 branch(es)

Have you created a minimal reproduction repository?

I have linked to a minimal reproduction repository in the bug description

[rarkins]

This is not a bug, so I have converted it to a discussion. You are misunderstanding the difference between a major update (eg 0.x to 1.x) and a breaking update (which 0.2.x to 0.3.x may be). 0.2.x to 0.3.x is a minor update, so current behaviour is correct. Add a matchCurrentVersion pattern to your package rule if you want 0.x packages excluded

[Mknight492]

I would have though the docs are about providing relevant useful documentation even if it's due to a misunderstanding of semver which, to be fair, has been debated extensively.

[HonkingGoose]

Our docs mentions that SemVer 0.x releases can break stuff whenever they want, but it's in the Key concepts, Automerge page. ¹ That's probably not the first place people look when they're configuring the matchUpdateTypes config option for dependencies. 😄 Anyway here's the quote:

Automerge non-major updates

Non-major updates in SemVer ecosystems shouldn't have breaking changes (if they follow the spec), so many users enable automerge for these too:

{
  "packageRules": [
    {
      "matchUpdateTypes": ["minor", "patch"],
      "matchCurrentVersion": "!/^0/",
      "automerge": true
    }
  ]
}

The matchCurrentVersion setting above is a rule to exclude any dependencies which are pre-1.0.0 because those can make breaking changes at any time according to the SemVer spec.

@rarkins do you want me to add a warning admonition about SemVer 0.x making breaking changes whenever in the matchUpdateTypes docs? ²

Footnotes

1. https://docs.renovatebot.com/key-concepts/automerge/#automerge-non-major-updates ↩

2. https://docs.renovatebot.com/configuration-options/#matchupdatetypes ↩

[HonkingGoose]

See:

• docs(config options): warn about SemVer 0.x packages #21747

[jorenbroekema]

@rarkins You mention that a major update is always the "x" in the "x.y.z" format of semver, but this is actually a lot more nuanced and potentially flat out incorrect. semver/semver#915

There is a lot of discussion even within the semver repo about what is "major, minor, patch". From what I understand from both the semver specification and that discussion is that major minor and patch are not hard-coupled to x.y.z and that if you have 0.0.z then z = major, because there are no patches in 0.y.z and there are no patches nor minors in 0.0.z, any bump there is major.

It's quite annoying that the semver spec and maintainers are being so ambiguous about this, but the truth of the matter is that within the NPM ecosystem, the behavior is very clear and that's if you specify 1.0.0 as a dependency version, it will not install anything other than 1.0.0, if you use the ^ caret, it will pull the latest minor + patch within the major and if you use the ~ tilde it will pull the latest patch.

Once you use ^0.1.0 it will still pull the latest minor + patch within the major but the "y" is the major, so only "z" is bumped.
If you use ^0.0.1 it will still pull the latest minor + patch except there are no minors and patches here because "z" is the major, so using a caret is pointless when using 0.0.z, same for using tilde when using 0.y.z, they don't do anything in those cases and you will get the exact version you specified

I've had multiple users of my package complain that I've erroneously added breaking changes in minors / patches and I keep having to tell them that I am not in the wrong for putting a major change in a "y" bump in 0.y.z or putting a major change in a "z" bump in 0.0.z , after all this is how NPM implements the semver specification.

So, I disagree that this is not a bug, it is most definitely a bug in the semver versioning scheme for renovate if its goal is to be aligned with how NPM implements the semver spec.

It's not even your (or whoever created the NPM scheme thing for renovate) fault either, semver as well as the NPM docs on how it implements semver are ambiguous at best and completely lacking at worst to explain this convention.

[rarkins]

I disagree, I think the semver 2.0 spec is clear enough that 0.0.2 isn't a "major update" or "major release" even if it might be breaking.

Feel free to add a new versioning scheme to Renovate which treats every 0.x release as major though.