Depending on release number instaed of commit

[AbdoDabbas]

• Replaced the old way of depending on commit with new one depending on release number only, and even check if release number is valid one (coz some packages doesn't have one either).

• Added resolution for all packages to solve incompatibly questions that may appear during the installation.

[shawnlonas]

@AbdoDabbas , the reason I choose to go with a commit id instead of a version number is that I wanted to make sure (as much as possible) that bower would actually give me the exact code I expected.

I wasn't confident that if I choose to try to lock a particular version that it wouldn't at some level try to bump the version number because of some transitive dependency.

Also, is it possible that someone could change the content of a particular version without incrementing the version number? It is not typical, but I suspect that it might be possible (e.g., remove a tag and reapply it to a later commit).

It is certainly nicer to read a version number than a commit id, which is why I added the bowerLocker.lockedVersion object.

But I'm not a bower/git expert so I might be paranoid. If either of these could happen, I think the commit id is better. The commit id may be ugly but machines/programs don't care how ugly it is and if you pull down the same commit id you can be extremely confident you got the right package.

Minimally, we should have better fall back behavior and warnings when something unexpected is encountered.

[AbdoDabbas]

You're right about your concerns, but when we depend on commit id it'll take ages to finish installing all the packages, I tried only one package which is jQuery, I think after locking and trying to install it's downloading the whole commit and then apply to it , locally, the bower install to get the package:

How can this latency be minimized or get rid of it ?

[shawnlonas]

@AbdoDabbas , I have noticed some latency on occasion but simply chocked it up to the delay of loading resources from external repos. As we only run the bower install initially, or to update, it was never an issue for us.

I believe bower does employ a caching system, so it may cache it by version, commit, or both. That may account for some differences.