Why not make versions fixed in bower.json

Question

I know most projects have minimum versions defined in bower.json for a lot of libraries.

Something I don't understand is that would this be risky that if something updates and have break-changes or bugs, it will affect your application without you knowing it? What is the design thinking behind this?

Thanks!

Answer 1

We have just faced that exact issue on a project I am on, and the solution was to change our bower.json file to target fixed versions.

Specifically, we were targeting angularjs ^1.4.8. In AngularJS v1.6,

$location now uses '!' as the default hash-prefix for hash-bang URLs, instead of the empty string

For better or for worse (mostly for worse) we had some hard-coded urls in a different application that pointed to this project that broke once bower automatically installed AngularJS 1.6 as part of our automated build process.

The solution was to simply lock down our versions rather than relying on the latest bug fix (i.e prefixing version numbers with ~) or minor build (i.e. prefixing version numbers with ^).

I think the reason that package managers like bower and npm default to dynamic versions is that they rely on semantic versioning, and in theory you should only encounter breaking changes when the major version number changes. Semver uses a major, minor, bugfix pattern. When the bugfix value is incremented it indicates that one or more backwards-compatible bugs have been resolved. When the minor version is incremented it indicates that new backwards-compatible functionality has been added. When the major version is incremented it indicates that new, breaking changes have been introduced.

The problem with this is that firstly, it relies on the package developer to respect the semver rules when they make changes to their packages, and secondly, even when semver is respected it can still lead to problems (as in the example I provided above).