Note: I’m new to version numbering. Please excuse my ignorance.
I have a project where an attempted major release (Version B) was abandoned then later re-attempted and release (Version C). Each version has major changes from the previous version that I wouldn’t consider an minor update. Little to nothing of Version B made it into Version C.
Version A (1.0)
- Developed, released, updated, etc.
Version B (???)
- Developed, suspended, abandoned.
Version C (2.0)
- Developed, released, updated, etc.
I feel like I should have version them like so, but worried about confusion of the missing version:
- Version A (1.0)
- Version B (2.0)
- Version C (3.0)
I wouldn’t mind a missing version number unless it is a marketing nightmare. From a development view point it’s simply a pointer and once you make it past a certain point the previous versions only served as lessons to build future versions. Like you said – little of Version B made it into Version C so internally what’s the point of acknowledging the existence of Version B?
Marketing – there are plenty of companies that will skip a version number. If customer gets confused just tell them you made such great strides in bettering your product you skipped a whole version. The other side is sometimes customers get this feeling that if they receive a version 2.9 of a software package they are entitled to a free copy of version 3.0. After all – it was on the heels of 2.9. Stop them in their tracks and take some more money for your hard work by a naming convention of 4.0.
That also will help with announcing your EOL by allowing you to EOL the non-existent version and previous making it sound like you’re a prince since you main people out there with your newly EOL version of software look like they’re already one version off.
It’s a mind game – you just have to take control of Russia and China before your opponent does. That’s why they call it Risk.