Is there an equivalent scheme to Semantic Versioning for non-API software?

Question

I really like the Semantic Versioning scheme but it really only makes sense for APIs, since the focus is on breaking changes and backwards-compatibility. For non-API, e.g. end-user software, many of the rules don't make much sense anymore. For example, the very concept of backwards-compatibility doesn't really mean anything; the user experiences new features or they don't, fewer bugs or they don't, etc. I would however benefit from a clear scheme for x.y.z versioning that follows the spirit of Semantic Versioning so that the users can have some idea what to expect from new version numbers if they are familiar with the scheme.

I tried sketching something such as:

• Bump z if making internal changes to code (e.g. bug fixes, refactoring) that don't change the user experience. May include new "internal" features.
• Bump y if adding features that change the user experience beyond bug fixes to current features.
• Bump x...???...radically different changes to user experience? What is radically different?
• Initial alpha development occurs as 0.0.z
• First beta-testing release is set to 0.1.0 and remains as 0.y.z
• First user release is set to 1.0.0

Another idea is to make x bumps when features that are removed since some users might rely on them, but that might seem unwarranted in some cases. (Say you know all of the users and they all want a very minor feature removed. Going from 1.0 to 2.0 would be somewhat counter-intuitive.)

This is more subjective than Semantic Versioning because it's a lot easier to objectively identify backwards-compatible features and breaking features of APIs. Are there any "standardized" versioning schemes that I might explore for more guidance?

Answer 1

I've been searching for something similar myself, but have not found anything "official." Here's how I've been doing my version numbering lately though.

Given x.y.z

• x = Increment whenever you redesign the user experience. For example, you re-arrange things on the main interface like the way Microsoft did with Office 2003 vs. 2007. If your application stores user files or settings, this number should also be incremented if the changes will not be backwards compatible with the old files or settings.

• y = Basically increment whenever you add a new new subroutine/function. Generally things like adding a new menu item or button will fall into this category since you'll have to write a callback to handle the click event on the menu item or button. Another example would be any changes to the code that don't make a noticeable difference to the user, but improve manageability (e.g. you finally got around to writing a class to manage your settings file). Reset this number if x is incremented.

• z = Increment whenever you fix a bug. Reset this number if x or y is incremented.

Note: Personally, I like to think that if you get y into the double digit numbers, it's time to consider a redesign of the user interface which would lead to an increment of x.

Answer 2

If your software saves data files or reads config files, then at a minimum the format of those files is your "API" and therefore changes in that format would in principle justify bumping X.