Bower versioning best practise?

Question

I am wondering how can I ensure that my bower version configuration will be workable in the future? E.g. I have already touched multiple projects, which either tell to use

">=1.0.0"
"~1.0.0"

Afaik the

">=" tells that all versions above 1.0.0 are fine
"~"  tells all versions/minor updates on 1.0.x are fine

To be more specific:

"dependencies": {
  "angular": ">=1.3.0",
  "bootstrap": ">=3.2.0",
  "jquery": "~2.1.0",
}

Of the day of writing this code following version configuration was included:

angular:   1.3.1
bootstrap: 3.2.0
jquery: 2.1.0

today you will get included:

angular:   1.4.0
bootstrap: 3.3.4
jquery: 2.1.4

From the point of the developers integration of the lib this features are fine on the beginning of the development. You have not to mess around with the painful dependency management of the libs and versions. But as soon as it gets tested the version should be fixed to defined versions.

I have already touched multiple projects which got broken after a very short period of 3 months, since the libs got updated to different versions, which either are incompatible to each other or some features got broken. So either the build was not working any more or even more bad, issues arise on client side.

What is the best practise to get rid of such version issues on the long term projects?

Answer 1

At the moment there is none, if your only option is bower. A lockfile a la composer or a shrinkwrap mechanism a la npm is in the works however it seems to have stalled as there are currently not enough contributors/maintainers to test the feature and maintain it in the long run.

UPDATE:
Since we now have yarn you can opt to use that, which uses a lockfile mechanism as the default behaviour. The only caveat is that it uses the npm registry which means that either some packages haven't been registered there yet, or have been namespaced like Google's Polymer which you might have to watch out for.