I often see myself releasing new npm versions as soon as I fix bugs, but this feels so wrong.
So I would like to ask you guys, what are best practices to release versions (major, minor and patches) of software in general, but having the NPM ecosystem in mind.
As developers we get excited when fixing bugs and get our code working but how advisable it is to loosely publish new versions at will and what impact it has on users?
Release as often as you want, so long as you follow SemVer (semver.org). NPM has assumptions built in that package authors will follow SemVer; particularly in the way it auto-updates when people specify dependencies with ^, ~ or .x notation.
So if you release ten updates, each with a bugfix version increment (1.0.1, 1.0.2, etc) and no breaking changes, people consuming your package who have opted in to auto-update patch versions get the fixes automatically. That is totally cool.
If you _add features _without any breaking changes, then increment the minor number, eg. 1.2.0 -> 1.3.0. Also cool. Do this as often as you like.
If you make a breaking change, update the major version. 1.x -> 2.0.0. While you wouldn't want to do this constantly (it's a bit annoying), it's still legitimate versioning. If you have lots of breaking changes, those I recommend you batch into a single release with plenty of documentation and an upgrade guide.
What would be totally wrong... would be releasing breaking changes under the wrong version number. That is if your live version is 1.2.3 and you break your API in 1.2.4 so peoples code stops working - expect people to be really upset. Release you breaking change in 2.0.0 and all is well.
Do not be afraid to increment your numbers! There is no actual harm in updating numbers. Remember you can release as many as you want, 1.2.45 is entirely legit if you release 45 bugfixes on top of 1.2 (although it's unusual to have that many updates in a 1.0+ or non-beta version, it's legit numbers).
For more of my opinions on SemVer, have a look at webdirections.org/blog/video-ristretto-ben-buchan… :)
Trust your own justice. If you feel like all important bugs are fixed at a specific moment and all tests run green, go for it.
I wouldn’t release a version for every Bugfix. But you fixed a bunch, no blocker issue open and maybe one or two little features implemented, go!. Everyone has its own rhythm. Just find yours and you’re good.
I always like it when new packages comes down the pipeline. :)
Nobody like to pay for broken software, so bug fixes we release as soon as they are available.
But we find people get irritated with microcrap type constant updates, so we release updates at max quarterly at min yearly.
That's just our policy though.
Gergely Polonkai
You have to believe in things that are not true. How else would they become?
As often as you like, but stick to it.
If you fix a security bug, fix and release immediately, and possibly remove all versions having that bug; this may annoy some of your users, but not as much as a security breach. If you fix a major bug, release as soon as possible. If you fix a bug hitting only a few users, release when you see fit.
If you add a new feature, release a beta or RC. When you get some feedback, fix bugs (if any) and release a new minor.
If you remove a feature or change an old one so it breaks API (or ABI, if apylicable; I don’t think it’s relevant to NPM packages), release a beta/RC, wait for the results, and do the major release. I do this type of release as rarely as possible, and if I do, I break the old API as many places as possible, if that makes my library easier to use.