8

I'm providing accompanying package that matches the version of the main NPM package, already in major.minor.patch format (e.g. 1.3.1).

I don't want to break version conformity between main and accompanying package. Is it possible to release intermediary subpatches for accompanying package that match

>=1.3.1 <1.3.2

semver constraint? Similar to 1.3.1.1.

Even if not possible to match the constraint, what's the convention for the patch for 1.3.1 to make it not overlap 1.3.2?

Estus Flask
  • 206,104
  • 70
  • 425
  • 565

1 Answers1

4

As http://semver.org/ states

Given a version number MAJOR.MINOR.PATCH, increment the:

  • MAJOR version when you make incompatible API changes,
  • MINOR version when you add functionality in a backwards-compatible manner, and
  • PATCH version when you make backwards-compatible bug fixes.
  • Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

As there is no sub-patches in SemVer, you could label your version with a label, for example 1.3.2-alpha1 or similar.

npm doesn't install labelled versions, commonly release candidates labeled with rc, alphas, betas and so on without explicitly stating you want to install such version.

Community
  • 1
  • 1
Pete TNT
  • 8,293
  • 4
  • 36
  • 45
  • I see. So I guess it can be either `1.3.2-patch.0-1.3.1` or `1.3.2-rc.0`, since none of them will match loose version constraints. – Estus Flask Dec 14 '15 at 22:44
  • @estus, exactly. But beware, versions like `1.3.2-patch.0-1.3.1` were sort of the reason `SemVer` was proposed: to have semantic meaning behind the version numbers alone. – Pete TNT Dec 15 '15 at 10:45