Better versioning system

[akashsaravanan-georgian]

I arbitrarily decided to go from 0.1.4-alpha to 0.2-alpha for the latest release. Would like some suggestions on the best way to go about with versioning for future releases.

[TheKevJames]

The semver spec is pretty complete and seems to be the generally accepted practice in most places! The spec on that page is pretty clear, but pullingout a bit into a tl;dr:

Given x.y.z:

While x < 1:

• Increment y if your release includes breaking changes or new features
• Increment z if your release is only some bugfixes/changes that don't affect how users integrate your code
• Once you're confident on your overall library interface being reasonably stable, release v1.0.0

When x >= 1:

• Increment x if your release includes breaking changes which users of your library would need to change their code to deal with
• Increment y if your release purely adds new functionality, eg. without breaking existing interfaces
• Otherwise, increment z

On "alpha" in the version number: generally speaking, you only need to mark a release as "alpha" if it's for internal testing before releasing the "real" version. eg. release 0.2.0-alpha to let some beta testers play around for a few days before you release v0.2.0 to a wider audience. It generally is meant to signify "this release is not ready yet", not "this package is not ready yet". I think you're using alpha to mark that this entire package is alpha? In that case, your version numbers being <1.0.0 will already do that trick!

[akashsaravanan-georgian]

I think that makes a lot of sense, thank you! We'll likely go ahead with the suggested scheme.