On Releases and Versioning

There's some weird thoughts about versioning. Mostly the idea that releasing a new version is a big deal.

It isn't. Got fixes tested and ready to go? Release them. Tag a new patch or minor version as appropriate and commit. Forget your plans or release scheduels or milestones. Rearrange them. If you library or application has any users at all they deserve to get the latest fixes and features.

Along the same lines, if you've broken backwards compatability, a major version shouldn't be a big deal either. Semver or any versioning system isn't about marketing or business practices or hype, it's about releasing software in such a way that users know things changed. When is something worthy of a new major version? When backwards compatability is broken. Simple.

A Practical Example

Since the beginning of January 2015, I've been running my first elasticsearch cluster in production. Since that time I've found a few issues. The elasticsearch team has an amazing response time and those issues were addressed very quickly.

But I can't use them. Because there's no stable version tagged (waiting on 1.4.3 at the time of writing). So I can trust my application to a -SNAPSHOT release (seems risky) or I can wait.

Versions are Cheap

Versions are cheap. Release as often as possible. Obviously breaking stuff (especially other people's stuff!) isn't good, so don't release broken things. Testing helps with that. If something broken does go out, release again immediately with the fixes.

If things are done, tested, and ready to go get them out there. Forget the schedule.

#