If you work for a well established organization, you likely follow a certain versioning scheme to keep track of software releases. However, if you are a startup or solopreneur, building a software product from scratch, selecting one type of versioning scheme over the other can be confusing.
Alpha release (a), beta release(b), release candidate (rc), pre-release tags, build tags, ISO 8601 scheme, negative numbering, resetting, skipping a few numbers to convey the significance of work. The list goes on.
There’s no universal method to number releases. You can adapt one of the number of different versioning schemes out there. Or make up your own.
As you progress further in your software development journey, your needs for versioning may evolve. But when you’re just starting out, I recommend that you go with Semantic Versioning (SemVer).
Semantic versioning follows a simple three-part numbering sequence in the Major.Minor.Patch format.
What does each number represent?
Patch: Bug fixes without altering the application functionality.
Minor: New feature additions while still remaining backward compatible.
Major: Significant feature additions, breaking the backward compatibility.
The backward compatibility is viewed primarily in the context of public APIs. Before you make updates to public APIs, it is a best practice to run two parallel versions of the APIs (new and existing) for at least a couple of minor releases to give your customers adequate time to move to the latest APIs.
Of all versioning schemes, Semantic Versioning perhaps offers the most meaningful and simplistic method to convey the degree of changes from one release to the next. So, when starting out, keep things simple and start with the release 1.0.0. And increment numbers in each subsequent release based on the types of work performed.