Renovate: Special handling for pre-1.0.0 npm updates

[rarkins]

Currently we don't do any special handling for pre-1.0.0 dependencies apart from whatever is built into semver when we handle range upgrades. But importantly, pre-1.0.0 upgrades may include breaking changes, e.g. 0.2.0 -> 0.3.0 may be have multiple backwards-incompatible changes.

The main reason for considering different handling is because users may configure automerge rules based on major/minor/patch semantics, and although they may feel comfortable automerging passing minor updates post-1.0.0, they may not want to do the same pre-1.0.0.

Full requirements and solution still to be decided. Feedback welcome!

[hutson]

Using _major version zero_ versioning is a common pattern where I work, and it led me to develop shifted-semver-increment to allow for incrementing versions when the major version is zero.

This aligns well with the caret notation supported by node-semver, though obviously the package does not align with the behavior of semver.inc.

[rarkins]

@hbetts I think a lot of authors/maintainers of major version zero packages still use "usual" semver practices but maybe like having the option of "I can make non-backwards-compatible versions whenever I want without having to make it obvious via version numbers". So for Renovate to assume every minor increment of a major version zero package is breaking might lead to a worse user experience..

[rarkins]

I think this problem could be improved greatly if "the community" made it taboo to use major version zero dependencies in production. A few big companies or open source projects could shift it greatly if they approached authors of packages they depend on and said "Hi, we really like using your package but for our next major release onwards we will have a policy against major version zero dependencies. We will fork and maintain a 1.x stream of your package unless you do" then it would shift things a lot.

[hkdobrev]

So for Renovate to assume every minor increment of a major version zero package is breaking might lead to a worse user experience..

Please, please, do keep it exactly how semver defines it - i.e. breaking changes to the API could occur between minor versions when the major version is 0. Libraries already use that when the major version is 0 and people rely on that. If renovate does something differently it would make it just more obscure and harder for people to use it who rely on a library using semver like that.

[rarkins]

@hkdobrev we are not really changing today or proposing to change anything semver defines. It's more that we allow people to set rules like "automerge" based on major/minor/patch concepts but the reality is those 3 terms mean something a little different in terms of risk when it's 0.x. They're still called major/minor/match increments in 0.x so we are not breaking the semver meaning, it's just we don't give users a way to specify different behaviour between 0.x and 1+.

One possibility we could do is keep support for major/minor/patch terminology for configuration but also add breaking/nonBreaking too. That way you could configure your automerge (to pick one example) as false for breaking and true for non-breaking. And we'd consider every upgrade for 0.x to be "breaking" hence no automerge ever. Also, this approach would allow people to choose not to do that too and consider patches in 0.x to be non breaking, if they really want.

Or if we want to be pedantic, we call them "maybeBreaking" and "hopefullyNotBreaking" :)

[DanielHabenicht]

Adding my support for this.

I think we should stick to the npm semver (https://docs.npmjs.com/misc/semver#caret-ranges-123-025-004) and make it default to not automerge breaking 0.*.* changes.

And than add a setting like shiftNpmBreakingChanges.
I don't know how this also applies to other package managers.

[fclairamb]

Dependabot handles it like what you're proposing @DanielHabenicht. Except they don't offer a way to handle it differently, which is causing the reversed issue.

The same rule applies to other packages managers. Semver has become the standard.

We could:

• Add a "minorPost1Version" value in the updateTypes, which makes it backward-compatible.
• Change the behavior of "minor" to make it semver-compliant (which is to behave like a major when the major is below 1) and add a "minorAlways", but that means breaking backward compatibility.

By the way in my top list of problematic packages I have:

• three.js which doesn't care about semver
• sentry's python integration

[rarkins]

I would expect that a packageRule like this can be added:

{
  "packageRules": [{
    "managers": ["npm"],
    "matchCurrentVersion": "<1.0.0",
    "automerge": false
  }]
}

If it's added after any existing automerge rules for patch/minor then it will take precedence.

[HonkingGoose]

My proposed default Renovate behavior

I think Renovate should never auto merge on 0.y.z npm packages. Those packages should be merged after a review of the change log, and be merged only after a manual approval step.

I think manual labor to verify a unstable package is a feature not a bug. A user should do the work to verify the update.

If a user still wants to auto-merge those unstable packages by opting-in, they should be warned that this is a bad idea, and that it will probably give them a headache down the line when their project breaks due to a auto-merged update...

Semantic Versioning 2.0.0 spec on Major version zero

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

On packages staying on 0.y.z versions

I think this problem could be improved greatly if "the community" made it taboo to use major version zero dependencies in production. A few big companies or open source projects could shift it greatly if they approached authors of packages they depend on and said "Hi, we really like using your package but for our next major release onwards we will have a policy against major version zero dependencies. We will fork and maintain a 1.x stream of your package unless you do" then it would shift things a lot.

I really like this idea!

Semantic Versioning 2.0.0 FAQ on releasing a 1.0.0 version

If your software is being used in production, it should probably already be 1.0.0. If you have a stable API on which users have come to depend, you should be 1.0.0. If you’re worrying a lot about backwards compatibility, you should probably already be 1.0.0.