Better versioning system
akashsaravanan-georgian opened this issue · 2 comments
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.
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!
I think that makes a lot of sense, thank you! We'll likely go ahead with the suggested scheme.