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?
The best suggestions I had so far:
#1
Make version 2 a development version, e.g. all releases 2.x.x are considered to be unstable. Then when done release version 3.0 as the stable release. So 2.x.x is to 3 what 0.x.x is to 1
This works nicely, but you will have to be very clear that version 2 is for development.
#2
Shoehorn all development after the dash of semver e.g.
2.0.0-0.0.1, 2.0.0-0.5.3 ...
This looks kind of horrible but works