You can pass a specific version number:
$ npm version 1.0.0 v1.0.0
Or, based on npm's major.minor.patch numbering scheme, pass the update type, and it will automatically increment that number:
$ npm version patch v1.0.1 $ npm version patch v1.0.2 $ npm version minor v1.1.0 $ npm version patch v1.1.1 $ npm version major v2.0.0
npm version updates the package.json file with the new version number If a git repository is present, the real magic happens - it automatically creates and commits a tagged version.
git commit, you can add an optional message:
$ npm version minor -m "Fixed broken menu, updated to %s."
%s is replaced with the generated version number.
While I've historically been horrible at software versioning, this feature makes it so easy that I might change. And because takitpart is a Node (DocPad) application, I'm going to start using it to version this blog.
I was very excited about doing a volume.issue.post versioning scheme, but I realized I was a software developer, not a magazine publisher. I also remembered this blog is supposed to be a proving ground for technological experimentation. I'm much more likely to update a plugin, rather than post. So, I've settled on:
Content-only updates (posts, etc) will increment the patch number. Major and minor software updates will reflect updates to the blog itself.
I'm hoping this will encourage better software development habits. I want my software updates to be more frequent, more focused, accountable, trackable, and most importantly, releasable. All too often I get caught up adding "just one more fix" to a release. I end up with yet another "megacommit" that is difficult to test, integrate, and release.
I believe tools like
npm version make it easier to implement good development methodologies, and that's just one more reason why I'm a huge fan of Node.
⚛ March 31 2013.