Image Description
Versioning your own software
You've made a program. Fantastic!
Now comes a surprisingly awkward question: what version is it?
Does my first release have to be 1.0?
No. If the software is still changing rapidly, you might begin with something such as 0.1.0. If you consider the public interface stable and the program ready for normal use, 1.0.0 can make perfect sense.
There is no requirement that version 1.0 be perfect. If there were, version 1.0 would be a mythical creature.
Do not use the version as a quality score
Version 0.9 does not have to mean 90 percent complete. Version numbers work better as identifiers for releases than as progress bars.
Write down your rules
Decide what causes each part of the version to change. If you use Semantic Versioning, that decision is largely made for you. If you use your own system, explain it somewhere in your developer documentation.
Keep releases identifiable
Once you have published version 1.2.0, avoid silently replacing it with different code while keeping the same number. If the code changes, make another release. It makes bug reports, support and your own sanity considerably easier.
A simple starting point
For a new project I would keep it boring. Start with a sensible development version, move to 1.0 when you are comfortable calling the public interface stable, and then increment versions consistently from there.
Boring versioning is good versioning. Save the excitement for the software.
Do you need Semantic Versioning?
Not necessarily. If other programs depend on your public API, SemVer gives those version numbers a defined meaning. For a standalone program, a simpler scheme or a date-based system can be perfectly reasonable.
Have a look at other ways to version software before deciding.
Further reading and external resources
Want to dig into this a bit more? These are good places to go next. If anything here ever disagrees with the official documentation, trust the official documentation.