So many times I hear developers arguing about how to label versions so here is the "right" way to do it ... well a widely accepted way!
Major versions are incompatible at the API level, as they can include any kind of change.
Minor versions are compatible with older versions at the API and binary level, and they can introduce new functions or deprecate old ones.
Patch versions are perfectly compatible, and they are released to fix defects.
Here are some examples to demonstrate the compatibility:
Original Version | New Version | Compatible? |
---|---|---|
2.2.3 | 2.2.4 | Yes Compatibility across patch versions is guaranteed. |
2.2.3 | 2.2.1 | Yes Compatibility across patch versions is guaranteed. |
2.2.3 | 2.3.1 | Yes Compatibility with later minor versions is guaranteed. |
2.2.3 | 2.1.7 | No Compatibility with prior minor versions is not guaranteed. |
2.2.3 | 3.0.0 | No Compatibility with different major versions is not guaranteed. |
2.2.3 | 1.4.7 | No Compatibility with different major versions is not guaranteed. |
Patch Versions
To retain perfect source and binary compatibility, a patch release can only change function implementations. Changes to the API, to the signatures of public functions, or to the interpretation of function parameters is not allowed. Effectively, these releases are pure bug fix releases.Minor Versions
Minor releases can introduce new functions, new symbolic and enumerated constants, and deprecate existing functions. In practice, this will not be a problem since upgrading to newer versions is always safe.Major Versions
Any kind of change can be made during a major version release. Particular types of changes that might occur:- remove or change constants
- remove (deprecated) functions
Minor Versions
Minor Versions
Minor
No comments:
Post a Comment