version control - Bower versioning best practise? -


hello bower experts,

i wondering how can ensure bower version configuration workable in future? e.g. have touched multiple projects, either tell use

">=1.0.0" "~1.0.0" 

afaik

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

to more specific:

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

of day of writing code following version configuration included:

angular:   1.3.1 bootstrap: 3.2.0 jquery: 2.1.0 

today included:

angular:   1.4.0 bootstrap: 3.3.4 jquery: 2.1.4 

from point of developers integration of lib features fine on beginning of development. have not mess around painful dependency management of libs , versions. gets tested version should fixed defined versions.

i have touched multiple projects got broken after short period of 3 months, since libs got updated different versions, either incompatible each other or features got broken. either build not working more or more bad, issues arise on client side.

so question is, best practise rid of such version issues on long term projects?

at moment there none, if option bower. lockfile a la composer or shrinkwrap mechanism a la npm in works seems have stalled there not enough contributors/maintainers test feature , maintain in long run.

update:
since have yarn can opt use that, uses lockfile mechanism default behaviour. caveat uses npm registry means either packages haven't been registered there yet, or have been namespaced google's polymer might have watch out for.


Comments

Popular posts from this blog

angularjs - ADAL JS Angular- WebAPI add a new role claim to the token -

php - CakePHP HttpSockets send array of paramms -

node.js - Using Node without global install -