When you start a new project everything is perfectly logical, 0.x means that it is not stable and the api might change. Then you release 1.0 and the api is supposed to be stable. Then 1.1, 1.3 should just be incremetal changes.
But then you want to start the work on version 2. Version 2 will have some major changes and be incompatible with 1. Where is this work supposed to go?
Some options:
- Put it in version 1.x, this is just wrong because 1.x is supposed to be an evolution from 1.0.
- Start versioning from 0 again with a different name, e.g. Foo2 0.1, then when you are done rename it back to Foo 2.0.
- Quietly use a different version scheme for all the work of version 2, e.g. build 123. And then when done release as version 2.0
- Start the work as 2.0. But 2.0 gives you the idea that is stable, which is wrong at that point.
Let's say you have released Foo 1.5. Then you want to start work on Foo 2. What version do you use for your first pre-release of Foo 2?
Nothing looks right to me, so my momentary conclusion is that Semantic Versioning is just broken. Would you please explain what I am missing here?
My understanding of it, assuming that you're currently on 1.1.0.
If it's a patch, make 1.1.1, 1.1.2, etc..
If it's a major change to the API, release 1.2.0, 1.3.0, etc..
If it's a major turning point in the evolution of the app, release 2.0.0.