Best practices for versioning project after dependency upgrade

Question

Say, my project have dependency N with version 1.0.0. Then something have changed, and I should depend on newer version - let it be 1.0.1.

OK, I'm incrementing dependency version, nothing else changes in my code. It looks like I should increment my own projects' version, but how exactly I should increment?

Should I increment only third number (so-called revision), or best practices here are more complicated. For example, may be, if we are changing projects' dependency minor value, we should do the same thing in the project itself?

Why would you want to increment your version number if your code didn't change? A version number increase communicates some sort of change in your code. I wouldn't really care that it can now build against a newer version of the dependency as well. — Benjamin Bannier, Oct 12 '12 at 13:02
@honk, if you are changing some dependency, you de-facto have new binary and I'm not sure that users of that binary shouldn't be aware that something had changed. Actually there is probability that something will be broken. — shabunc, Oct 12 '12 at 13:05
You didn't say you meant version of build artifacts, I was thinking more about source releases. — Benjamin Bannier, Oct 12 '12 at 13:07

score 9 · Accepted Answer · answered Oct 12 '12 at 13:07

I'm not aware of any best practices for this situation, so here's my take:

An updated dependency should be reflected in your version; let's take the example of MAJOR.MINOR.REVISION numbering scheme.

Any version change in a dependency should at least increment your REVISION number, but a bigger change, such as a MAJOR or MINOR change in the dependency version, should cause you to increment your MINOR version.

Although MAJOR version changes in dependencies often come with API changes, I wouldn't increment your own MAJOR version unless you've made more changes than just updating to a new MAJOR version of a dependency.

score 6 · Answer 2 · answered Jun 23 '13 at 10:16

Semantic Versioning is an attempt to codify the way version numbers ought to work.

In a nutshell:

Given a version number MAJOR.MINOR.PATCH, increment the:

MAJOR version when you make incompatible API changes,

MINOR version when you add functionality in a backwards-compatible manner, and

PATCH version when you make backwards-compatible bug fixes.

According to this, you shouldn't care about whether the change in the final product was due to changes in your code or changes in a dependency. If it adds functionality, change the minor version, if it doesn't, change the patch version, if it makes no difference at all (maybe you're not using the part of the dependency that changed), I think you don't need to update the version number at all.

score 1 · Answer 3 · answered Oct 12 '12 at 13:01

If you're only updating the dependency, that's a minor revision (barely any change to your code) so I would only update the third numeral. The second numeral is usually reserved for major updates (big bug fixed, new features, balance issues, etc) and the first one for a completely new version of the software.

Best practices for versioning project after dependency upgrade

3 Answers3