What version number should an unreleased project receive?

Question

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)

Answer 1

You should have two versioning schemes. An internal one, that follows the typical form:

major.minor.build.revision

And then a public facing one. With the public facing one, you can map your internal versions to "customer friendly" named versions. Like the hilarity around Java's naming strategies.

Answer 2

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.

Answer 3

If Version B was never released, then your Version C can be released with a public release number of 2.0. You don't have to admit to having internal releases that didn't make it. Your internal version number does not have to match your public release numbers, as long as you keep track of the mappings.

Answer 4

Multi-dot version numbering is a waste of time. KISS. Start with version 1, increment by 1, and just stick to whole numbers. If you're using a system forcing extra periods and digits, ignore them. Keep a good log of what's specific to each version, when it was released, to whom it was released, etc. Anyone deciding only by version number and not the "what's new" documentation on whether or not to upgrade is not anyone to be concerned about.