Running "bower install" in the presence of a bower.json file will install missing components, update components when the version in bower.json has changed, and prompt the user to resolve any conflicts that are not able to be resolved automatically. Running "bower update" does all of the same things, but seems to be better at conflict resolution.
This is a simplification of a real scenario I am have found myself in: I'm running Bower 1.3.12. Let's say my project is called Building. It has several dependencies, only two of which are relevant to this question. We'll call the dependencies Door and Lock. (We do use x.x.x semantic versions, but not version wildcards like ~ or ^. I'm omitting the patch number to make this easier to follow.)
Lock 0.2 requires Door 6.0.
Building requires both Lock 0.2 and Door 6.0.
After running bower install everything is happy.
Then Lock 0.3 and Door 7.0 are released. The new Lock uses the new Door:
Lock 0.3 requires Door 7.0
I want to use the new Lock and Door in my Building, so I change my bower file to reflect the new versions. What happens next depends upon which command I run. If I run bower update everything is happy.
But if I don't run bower update and instead run bower install, it prompts me to resolve a conflict. The conflict shows like this:
Door 6.0 required by Lock 0.2
Door 7.0 required by Lock 0.3, Building
I have defined Lock 0.3 in my bower file and the console shows that bower has already noticed that I want Lock 0.3 before asking me for conflict resolution. It still asks me to fix a conflict with the old version of Lock which should be evicted by the new version. There are no other dependencies that require Lock, so there is no conflict regarding which version of Lock should be resolved.
Given that, in what situation would anyone ever use bower install, when it seems that bower update does all the same stuff, plus being better at preventing manual conflict resolutions?