Software Versioning Cheat Sheet
ADVERTISEMENT
1{
S
OFTWARE VERSIONING CHEAT SHEET
.1523
v 1.2.0
.alpha
.test
.beta_10022013
F
M
M
P
OURTH NUMBER
AJOR VERSION NUMBER
INOR VERSION NUMBER
ATCH NUMBER
Number of build,
“What the client’s boss
“What the client asked for has
“What developers waited for
phase number,
dreamt of has been added.”
been added.”
has been added.”
nickname …
Major changes
Minor changes
Bugfixes
Rare, often used to
Backward incompatibility
Additional features
Improving existing features
solve “Mine is
Backward compatibility
longer than your”
developer
New technology used
Adding a new dependency
Dependencies change their
complex. Not
A dependency was replaced
major/minor/patch number
recommended.
We propose here some basic rules to help developers with version numbering. Where a rule already exists, stick to it! If
not, we recommend using this one.
Why do not use concrete dev examples to help deciding? Let’s take an example to show why not to use examples: while
performance is of major interest for a linear algebra computation library, it is less important for a web app. Hence, a
speed up of 2x for Lapack will deserve +1.0.0 on its version number (by the way, it would certainly need a major
conceptual change), while it will barely have +0.0.1 for Angry birds (and is likely to be achieved correcting a bug or
updating a dependency). That “user point of view” definition allows a more generic definition.
ADVERTISEMENT
0 votes
Related Articles
Related forms
Related Categories
Parent category: Education