SemVer is defined for public APIs only. If your development does not define such an API, you'll first have to interpret SemVer to clarify its use for software without public API or other forms of content.
You should not restart your versioning from 1.0.0:
- for practical reasons, in order to avoid the risk of any confusion with version 1, 10 and 100.
- for formal reasons, because SemVer-clause 4 reserves major version 0 for the development stage with unstable and public API, and SemVer-clause 5 reserves version 1.0.0 for the initial definition of the stable public API. In view of your wording, I understand that the next version would not be the first official version that defines the API. So 1.0.0 would not be compliant.
The rigorous approach of reverse analyse each of your past releases to determine their real SemVer version is to be avoided. For practical reasons: It would be very time consuming and the story of why you switched from version 136 to version 12.4.5 would not be very interesting to hear.
The most prudent would be to start at 136.0.0. It's a fresh start. Everybody will understand, and the version history goes upwards. I'd recommend this one if your product is already quite old very mature (e.g. monthly release in average) or if you don't want to answer unnecessary questions from your customers.
An alternative, if your product is still quite new (e.g. weekly release in average in the past). Could be so start at version 2.0.0. This could be justified by stating that you adopt a dotted versioning scheme and that you consider the old version as 1.3.5 and the next major version (after all you change the versioning logic!) is 2.0.0.
Now, if you're in commercial software, a pragmatic and often-used market oriented approach would be to take 2 major versions ahead of your biggest competitor. Your customers will understand that your product is the most advanced one. But as a software engineer, don't try to find an explanation: let the marketing department chose the most convincing narrative ;-) /* Needless to say: I cannot objectively recommend this last approach */
1.0.0
is a bad idea, because you can easily confuse the old versions1
,42
, etc with the new versions1.0.0
,42.0.0
. It makes parsing and comparing version numbers pretty unintuitive: 1 < 42 < 1.0.0?! Therefore, I recommend that you switch from135
to136.0.0
.