Consider using semantic versioning

[Redsandro]

sharp breaks my (re)deploy sometimes, because it doesn't mark breaking changes as 'major'.

One could argue that I need to change my package.json and lock versions. On the other hand, the default for npm install package --save is semantic versioning where minor and patch releases are installed automatically, and the major version is locked by default, AKA ^x.y.z.

Today (applause for the app running over six months) it was #1392. This is a breaking change.

Please consider using the first digit in the version number, and increase it when a breaking change is made.

I know in my specific case that would mean you'd be at 3.x.x now, and I know some people do not feel comfortable using version numbers above or equal to 1.0.0 as it implies commercial-grade stability, but it's okay.

Just do it:

Changelog

1.0.0

• New: Started using semantic versioning. (Consider using semantic versioning #1754)

Bam! 🎆

[Redsandro]

PS - I like this new version. 👍

[lovell]

Hello, did you see #1448 (comment) ? The tl;dr is that sharp v0.y.z not only conforms to but exceeds semver.

[Redsandro]

Hi @lovell I did not see that comment, thank you for pointing it out.

sharp currently places bug fixes and API additions in patch increments and deprecations and breaking changes in minor increments. This means the caret range operator ^ can be used when including sharp as a dependency.

Unless I'm missing something, this is false.

The ^ operator, I believe, which is the npm default, causes breaking changes in minor version bumps. Manually going back in package.json and changing the caret to tilde ~ will work in the interim, but I don't think it's desirable to give one dependency special treatment and remember to switch back at some point.

I'm missing something. The documentation says:

Caret Ranges ^1.2.3 ^0.2.5 ^0.0.4

(...) this allows patch and minor updates for versions 1.0.0 and above, [and] patch updates for versions 0.X >=0.1.0

So theoretically you're correct. However, I am observing across three different node and npm versions that this is not working as intended. This issue is empirical rather than theoretical. At the same time, I don't believe npm would have this issue persist over a long period, so I trust that somehow this is my own fault.

I hope 1.0.0 will be released soon, because it would fix some issues for me.

[Redsandro]

If anyone comes across this issue, I've done an npm init locally as a test:

{
  "name": "tmp",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "dependencies": {
    "sharp": "^0.21.0"
  }
}

npm install does indeed stay with [email protected]. My docker containers install 0.22.0. I think I broke something in the multi stage build process.

[lovell]

https://semver.npmjs.com/ is a useful tool to understanding semver as applied by npm.