Major / Minor / Patch should be treated like Semver for pre-1.0.0 dependencies

[msluther]

What would you like Renovate to be able to do?
A way to create PR groups based on either the concept of "breaking" vs "non-breaking" change or sem-ver matching. Currently we have something like this setup for our workflow to create a single-pr to group together all of the the "easy" package bumps:

  // Group together all non-major bumps
  packageRules: [
    {
      packagePatterns: [
        '*'
      ],
      minor: {
        groupName: 'all non-major dependencies',
        groupSlug: 'all-minor-patch'
      }
    }
  ],

Unfortunately for dependencies on packages that are pre-1.0.0 what minor/patch means could technically be a breaking change. (Frequently minor changes are treated as a breaking change and patch are more safe changes, though not strictly enforced). e.g. a version change 0.2.0 -> 0.3.0 will often contain breaking changes, and we'd like to separate that out of the "easy" package bump PRs.

Describe the solution you'd like
A way to group PRs that works like semvers ^ & ~, or a way to group prs based on whether the version change already matches the semver range defined in a package.json.

Describe alternatives you've considered
We're using the packageRules I defined above as it mostly gets there, but we just have to be extra dilligent there about pre-1.0.0 packages.

Edit: Updated to use feature-request template.

[rarkins]

0.2.3 —> 0.3.0 is still technically a “minor” update and we should not change that terminology. Further, you should be aware that according to semver, even a patch update for pre-1.0.0 may be breaking even though most library developers don’t break things for patch updates.

So if you decide that pre-1.0 minor updates and risky but patches are safe then be aware that’s entirely your opinion and not based on any standard. Personally I agree with you, but it’s no standard or agreed convention.

In summary, the terms breaking and non-breaking are more applicable here rather than major/minor/patch.

All that said, we can discuss how to make it possible for you to define rules according to that opinion. Possibly it can be done using matchCurrentVersion and updateTypes within a packageRule

[rarkins]

Also this is 100% not a bug, just to be clear. If you have subsequently have a feature request then please rewrite the description, otherwise we should close this.

[msluther]

Yeah, fair enough, I'll rewrite as a feature request. Maybe semver-matching (and we put ^ in our package.json) or breaking/nonbreaking. Probably the former is more applicable for our use case (we want to automate bumps to get on latest semver-matching builds as one pr-group, and separate prs for each non-matching change.

[rarkins]

If you want to group pre-1.0.0 patches and post-1.0.0 minor or patch then it might be possible already via config

[decompil3d]

Per the semver spec, major version 0 is considered unstable and thus the API may change frequently and in breaking ways. Typically, we think of stability based on the left-most non-zero value in the version number. So 0.1.0 -> 0.2.0 is breaking, but 0.1.1 -> 0.1.2 is not. So supporting some mechanism of grouping "breaking" vs "non-breaking" changes seems like the thing @msluther is looking for.

[rarkins]

So 0.1.0 -> 0.2.0 is breaking, but 0.1.1 -> 0.1.2 is not

Per the semver spec, such 0.y.z patches may also be breaking, although most authors do not do that and instead maintain backwards compatible between patches.

The spec states:

Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable.

(From https://semver.org/#spec-item-4)

What this means is that's it's not appropriate for Renovate to effectively say "I know what the says but I'm going to ignore that because the majority of library authors don't break things in pre-1.0.0 patches". But certainly we should support people implementing their own opinionated rules for their Renovate if they want to rely on pre-1.0.0 libraries all having backwards-compatible patches.

@msluther here is an alternative config I think will work as you intend:

  packageRules: [
    {
      matchCurrentVersion: "< 1.0.0",
      separateMinorPatch: true,
      patch: {
        groupName: 'all non-breaking updates',
        groupSlug: 'non-breaking'
      }
    },
    {
      matchCurrentVersion: ">= 1.0.0",
      minor: {
        groupName: 'all non-breaking updates',
        groupSlug: 'non-breaking'
      }
    }
  ],

Note: if you have more than npm dependencies then it would be best to wrap the above inside an npm: {} object so that it doesn't apply to the others.

I recommend checking this on a test repo first though, as I am not 100% sure that I've thought of everything.

I'm now closing this issue, as I found a duplicate issue I created long ago that we should use instead: #1257

@msluther if you want to follow up on the above config then please post a question to https://github.com/renovatebot/config-help