Sometimes you need to override the requirement of a dependency's version. Either you are trying out a newer one (like beta or just unanticipated releases), or you have to deal with a specific outdated release.

After all, the requirement of specific dependencies (in specific versions) is one the main reasons people use dependency management. In a nutshell, your project (your list of dependencies) is one document of requirements. And each dependency itself have also such a document (transitive dependencies, here we go).

In most systems, a specific dependency contains:

• location (in case of Bower it's managed by the tool)
• scope (Bower knows regular dependencies and special for development purpose only ones)
• name (i.e. angular)
• version pattern (either specific like 1.2.27 or ranges, see SemVer)

As a library plugin, we have to deal with different library versions. As this document was created, AngularJS 1.2.27 is the latest stable of the older 1.2-branch, and Angular JS 1.3.6 is the latest stable of the 1.3-branch. From time to time, we have also several alpha/beta as well as release candidate releases.

We are developing against a specific library (just like you are developing your webapp against 1-2 specific web browser). However, we have to ensure it would work in all other supported versions, too (just like you are testing your webapp against other browsers at the end of the day).

Said this, we have to choose one specific version pattern which is our current recommendation. It does not mean other versions will fail, it does not mean other versions are unsupported. But we can choose only one pattern. Furthermore, we have to reuse this specific pattern anytime we are referencing to library part of a Angular JS release (i.e. angular-cookies).

Whatever the case may be, the user can manage always the dependencies. In bigger projects, it is often not unusual to manage the directive dependencies as well as the transitive ones. Speaking of Bower, the terminology is called resolution. Other systems are calling it pinned or managed.

Regardless which specific version or which version range any other dependency is requesting, you have to full control to override this. Perhaps you are using resolutions already, because it is used for solving conflicts (just another variant of different versions).

Let's say you are using a plugin which requires angular#~1.2.26 and you are want to use Angular JS 1.3 now.

{
  "resolutions": {
    "angular": "~1.3.0"
  }
}

Voilà! Everytime Bower has to resolve a dependency named angular, it will resolve [sic!] to ~1.3.0.

The same applies to downgrading a version. Because it could be a version range, you are able to target specific pre-releases for testing purpose, too.

And speaking of AngularJS, you should not forget all the other related resources like angular-cookies, angular-route or angular-mocks (and more).