I would suggest that for our version numbers we use Semantic Versioning, where we start at 0.1.0 and then the numbers increment at Major.Minor.Patch
I see that the intent is to have a stable branch in Git called master and then the work will be done on the development branch. In this case, what I have done before is anytime that development is merged into master, then the corresponding number is incremented and the merge commit is tagged with the new version number.
Thoughts?
My quick, non-elaborated answer: maybe.
Semantic versioning makes a ton of sense for APIs. Its benefit outside of that is much less clear.
Short list of recommended reading, in no particular order:
https://gist.github.com/jashkenas/cbd2b088e20279ae2c8e
https://codeblog.jonskeet.uk/2019/06/30/versioning-limitations-in-net/
Counterpoint, some part of this project is going to have an API as has already been mentioned, and I don’t think it makes sense to have two types of version numbers.
Sounds like a fair counter-point in principle, but I disagree in that it can make perfect sense (and is not uncommon). [edit: on second thought, maybe it’s a bit uncommon, yes]
It might be sensible to make the API stable and opt for scheduled releases for the main software. It’s too early to decide, I’m afraid.
I’ll keep this in mind (suspended, as a low-priority background process) and postpone the decision until we are closer to actually making a first release.