Menu
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:
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?
597
The unique identifier you use may be name-based or number-based, but most Python packages use semantic versioning. In semantic versioning, a version number consists of three integers A.B.C, where A is the “major” version, B is the “minor” version, and C is the “patch” version.
Semantic Versioning is a 3-component number in the format of X.Y.Z, where : X stands for a major version. The leftmost number denotes a major version. When you increase the major version number, you increase it by one but you reset both patch version and minor versions to zero.
Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version.
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.
86
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.
28
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
