What to use as an initial version?
I usually start my projects with a version 1.0.0. As soon as I have some stuff together, I release it as 1.0.0 and move on with 1.1.0.
However, this leads to usable but not exactly feature complete version 1.0.0 of most stuff I write. I then add features and get to a decent version somewhere around 1.6.0. Many projects start with version 0.1.0, which will be as usable as my 1.0.0.
What would you suggest doing? Start with 1.0.0 or 0.1.0?
The last number is for bugfix releases only by the way. You can think of my 1.0.0 as 1.0 and 0.1.0 as 0.1 is that's easier for you.
Answer
The Semantic Versioning 2.0.0 standard provides the 0.y.z space to indicate that your project does not have a stable public API:
Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
It is suggested to start at 0.1.0 and bump the minor version on every breaking change to the public API. You can increment to 1.0.0 when you are in a position to appropriately control and manage these breaking changes:
Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes.
The benefit of using the 0.y.z space is that you will not reach a high major version, e.g. 142.6.0, during initial development. It tends to be industry convention to avoid high major version numbers, partially for marketing reasons, but this may not be relevant to you.
Semantic Versioning applies specifically to projects with public APIs, but is often applied in other contexts with an alternative notion of "breaking change", e.g. large changes to GUI interfaces.