When you write software-artifacts, each of them has a version. But how should the version numbers be created? Are there several rules when to increment which part?
Parts of a version-number
A version number should consist of a group of 3 numbers separated by a dot. The first number is called major, the second minor and the third one patch. After that a small text called meta-data can be appended to the version-number, but this is not discussed here.
Rules for incrementation
When you create a new version of a new component, you should follow these rules.
Major is incremented when you make API changes incompatible to the current version
Minor is incremented when you add functionality that is backwards compatible
Patch is incremented when you fix a bug and the API is not affected
An API change means you change an interface or a class such that an existing program that uses it, cannot use the new version without adaption. This includes changing the signature of already existing non-private functions, remove an existing non-private function, changing the access specifiers to a lower access level.
Adding functionality means adding (new) non-private functions or overloading existing ones. If the parameter-list of an existing non-private function is changed, it is an API-change.
Fixing a bug means only changing code of a non-private function for correcting errors, but without changing expected behaviour.
General rules
If you need a version number for a component you should obey these general rules.
Every release gets a new version-number
Patch is reset to 0, if Minor is incremented
Minor and Patch are reset to 0, if Major is incremented
Meta-data may be appended after Patch
If you act on these rules you are using semantic versioning.
Advantages of using semantic versioning
If you are using a component supporting semantic versioning, you can safely upgrade to a version with the same major, but higher minor or patch level.
If you want to use a library with a higher major, then you know that it might be incompatible with your code.
Conclusion
Using semantic versioning makes it easier to use components and know about affected code. There is no disadvantage or reason why not to use these rules.
Settings for privacy
This page uses cookies to save the user's privacy-settings. We do not have a stake in how linked pages analyze, process or save data. Since, we only show such content after the agreement of the user.
This applies to sharing-functions of social-media-content like twitter or facebook and embedded videos of youtube.
Einstellungen für Datenschutz
Diese Seite verwendet Cookies, um die Datenschutzeinstellungen des Benutzers zu speichern. Wir haben keinen Einfluss darauf, welche Daten verlinkte Seiten analysieren, verarbeiten oder speichern. Aus diesem Grund werden solche Inhalte nur nach vorheriger Einwilligung des Benutzers angezeigt.
Dies betrifft Funktionen für das Teilen von Inhalten auf sozialen Medien (Twitter und Facebook) sowie eingebundene Videos von youtube.