Release 1.0

[mansona]

Feature request

Release the current stable version as a 1.0.0 version

What are you trying to achieve?

I would just like the server ranges to be a little less surprising 🙈 If I specify ^0.34.0 I won't get any of the "patch" versions in my project that depends on this. And this has been pretty stable for a long time!

[lovell]

This may well happen as a result of #3750

If I specify ^0.34.0 I won't get any of the "patch" versions in my project that depends on this.

Are you able to explain a little more about what you mean by this? Specifying ^0.32.0 will include all the patch releases from v0.32.0 to what is currently the latest v0.32.4.

[elgordino]

I can try to explain @mansona 's comment.

While ^0.32.0 does allow for patches of that release eg 0.32.4 it does not allow for the next release, say 0.33.0 whether it contains breaking changes or not.

Moving to a 1.0.0 release will allow for ^1.0.0 to include all minor and patch releases. Then breaking changes can be released in a theoretical 2.0.0.

This allows differing packages with a sharp dependency to work together more effectively as one package can request a higher minor release than another without having to duplicate the dependency.

[lovell]

The changes being introduced by #3750, where prebuilt binaries and the libvips dependency all move to package manager control, will hopefully allow more efficient semver matching and make breaking change management more consistent/explicit.

As you suggest this may also result in fewer duplicates for some installation trees, although I always strongly encourage everyone to update to the latest version, as both a direct and transitive depedency.

If you'd prefer, an alternative way to think about the current situation is that sharp is on major version 32 :)

[o-alexandrov]

@lovell please kindly consider to release the next version as 1.0.0 or 34.0.0.
Unfortunately, it's rare, when developers use ~ (to allow only patch x.x.X updates).

• typically, you'd see projects where sharp's version is defined as, for example ^0.33.0. It means when you release 0.34.0, next time sharp is reinstalled, it would pick up 0.34.0, since caret means all x.X.X updates are allowed (i.e. up to 1.0.0).
  • in other words, breaking changes from minor versions are automatically installed when sharp is updated

The above makes it slightly harder to maintain such projects, so please kindly consider to conform to semantic versioning.

[lovell]

breaking changes from minor versions are automatically installed when sharp is updated

This is not the case for semver pre-1.0.0, as the caret ^ operator will introduce only patch increments.

please kindly consider to conform to semantic versioning.

sharp currently conforms to semantic versioning.

[o-alexandrov]

@lovell thank you, pre-1.0.0 actually does work as you said. I probably never actually checked such different pre-1.0.0 UX (talk about principles of least astonishment 😅).

sharp currently conforms to semantic versioning.

Does it? According to semver.org item 4, major version 0 is for initial development and public API isn't stable.

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

[lovell]

In that case sharp exceeds semver compliance 😄