Menu
I was reading up on versioning with npm, and apparently it provides a nice convenient command for bumping your package versions.
npm version [<newversion> | major | minor | patch | premajor | preminor | prepatch | prerelease] prerelease
Lets say your package starts at version 0.0.0
npm version prerelease => 0.0.1-0
npm version prerelease => 0.0.1-1
Basically just bumps the number after the dash
prepatch
Starting from 0.0.0 using pre[major|minor|patch] instead...
npm version prepatch => 0.0.1-0
npm version preminor => 0.1.0-0
npm version premajor => 1.0.0-0
patch
Starting from 0.0.0 using patch...
npm version patch => 0.0.1
npm version patch => 0.0.2
I understand the rules for bumping major minor and patch versions, but what is the standard convention for versioning things prior to 1.0.0?
365
The NPM ecosystem uses Semantic Versioning (SemVer) which follows the convention of MAJOR. MINOR. PATCH (e.g. 1.3. 2 ). This is to differentiate between versions that introduce major breaking changes, minor backwards-compatible changes, and patch changes for small fixes.
For example a dependency with a version of * would equate to any version that was greater than or equal to 0.0.0, while 1.* would allow versions greater than or equal to 1.0.0 and less than 2.0.0.
When you need to downgrade npm , you need to run the npm install -g npm@<version> command followed by the version you want to install. As you can see from the snippet above, the npm install command will overwrite any existing package with the same name.
For npm install specific version, use npm install [package-name]@[version-number]. Use npm view [package-name] version to know the specific latest version of a package available on the npm registry. Use npm list [package-name] to know the specific latest version of an installed package.
I have not seen prelease versions utilized pre-1.0.0. It seems fairly pointless since the public API is not finalized yet. They become useful after 1.0.0 is released.
From semver.org:
Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.
and:
A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. ...A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version.
The conventions I have seen pre-1.0.0 include using patches for bug fixes/typos and minor versions for any significant modifications. The conventions are less strict pre-1.0.0 since no public API has been guaranteed yet.
Prelease versions come in handy when you want to share some early features with the community.
For example, at the time of this writing, the latest stable release of npm-check-updates is version 1.5.1. Some of the new features I have added have introduced backward-incompatible changes, so to conform to semver I will have to release them under 2.0.0. Yet, I don't want to release 2.0.0 as the latest stable version until it has been more thoroughly tested by the community. Thus, I have published a prerelease version (using npm publish --tag unstable) versioned at 2.0.0-alpha.1. Community members can install the prerelease version (with npm install -g npm-check-updates@unstable) to try out the latest features while a normal npm install -g npm-check-updates will continue to install the stable 1.5.1 version for most users. When the prerelease has proven itself, I can easily publish it as the new stable at 2.0.0.
161
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
