{"action":"created","issue":{"url":"https://api.github.com/repos/appium/appium/issues/5317","labels_url":"https://api.github.com/repos/appium/appium/issues/5317/labels{/name}","comments_url":"https://api.github.com/repos/appium/appium/issues/5317/comments","events_url":"https://api.github.com/repos/appium/appium/issues/5317/events","html_url":"https://github.com/appium/appium/issues/5317","id":92222530,"number":5317,"title":"Discussion: strategies for fixing dependencies in Appium","user":{"login":"jlipps","id":605053,"avatar_url":"https://avatars.githubusercontent.com/u/605053?v=3","gravatar_id":"","url":"https://api.github.com/users/jlipps","html_url":"https://github.com/jlipps","followers_url":"https://api.github.com/users/jlipps/followers","following_url":"https://api.github.com/users/jlipps/following{/other_user}","gists_url":"https://api.github.com/users/jlipps/gists{/gist_id}","starred_url":"https://api.github.com/users/jlipps/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jlipps/subscriptions","organizations_url":"https://api.github.com/users/jlipps/orgs","repos_url":"https://api.github.com/users/jlipps/repos","events_url":"https://api.github.com/users/jlipps/events{/privacy}","received_events_url":"https://api.github.com/users/jlipps/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/appium/appium/labels/NeedsTriage","name":"NeedsTriage","color":"ededed"},{"url":"https://api.github.com/repos/appium/appium/labels/Question","name":"Question","color":"009800"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":4,"created_at":"2015-06-30T23:15:31Z","updated_at":"2015-06-30T23:35:25Z","closed_at":null,"body":"### The Problem\r\n\r\nOne of the downsides of breaking Appium apart into multiple independently-developed and -tested projects is dependency management becomes more complicated. NPM's package.json gives us various ways to specify dependencies. We can specify exact versions, or use symbols that denote version ranges. In most of the Appium packages, we use `^` for dependencies, which means \"get me the latest patch version\". If everyone is following semver, this should be OK, but sometimes 3rd parties (or, sadly, ourselves) might inadvertently release a broken package as a patch release. This would immediately break upstream packages for anyone who's doing a fresh `npm install`, and we would be none the wiser. We need a system for ensuring this kind of problem doesn't occur.\r\n\r\n### Possible solutions\r\n\r\nHere are some possible solutions (maybe there are others):\r\n\r\n0. Stop using `^` in any project. Always specify exact dependency versions.\r\n    * Pros: complete control\r\n    * Cons: huge dependency management headache. We will probably more frequently release a patch change that _doesn't_ break than one that does. To have to explicitly update the entire dependency tree and re-publish to take advantage of this change would be onerous.\r\n0. Use `^` only for projects we own (trusting that we will not release breaking changes as patch releases). Use exact versions for 3rd-party deps.\r\n    * Pros: we can avoid 3rd-party breakages while taking advantages of auto-upgrading packages whose quality we can control. If something breaks, we can release a new patch version of the broken package quickly and the problem will be resolved.\r\n    * Cons: this doesn't fix sub-deps of 3rd-party deps breaking. It also keeps us somewhat open to breakages that are our own fault.\r\n0. Use `^` for all projects, but use `npm-shrinkwrap` when publishing the top-level project (appium/appium) so that `npm install appium` always returns the exact same subset of dependencies for a particular version of appium.\r\n    * Pros: We are guaranteed that every Appium install will involve the same deps.\r\n    * Cons: npm shrinkwrap is not entirely user friendly (or entirely unbroken, from what I can tell). There is confusion around when we would run shrinkwrap, whether we would keep it in source control, how it handles dev dependencies, and so forth.\r\n0. Use `^` for all projects, and use `npm-shrinkwrap` when publishing all projects.\r\n    * Pros: even more control than the previous solution. It also means we don't have runaway dependency problems in each project. This is useful if, say, another project was using appium-adb on its own, or appium-xcode on its own. We would be adding shrinkwrap protection to each one.\r\n    * Cons: all the cons of the previous solution, plus we get back into the realm of having to make explicit updates and re-publishes to deps when sub-deps change.\r\n0. Stop using `^` in any project. Always specify exact dependency versions. Only on this idea, write an automated tool (part of Turtledeps, perhaps) to update dependents, run tests, and re-publish automatically. (I.e., this is the same as the first option with some automation)\r\n    * Pros: mixes complete control with lesser management headache\r\n    * Cons: it's unclear whether an algorithm exists to safely run this logic. It'd probably require a setup involving a bunch of git clones and test environments ready to go. Might be more work than is worth it.\r\n\r\nSo let's discuss!"},"comment":{"url":"https://api.github.com/repos/appium/appium/issues/comments/117372647","html_url":"https://github.com/appium/appium/issues/5317#issuecomment-117372647","issue_url":"https://api.github.com/repos/appium/appium/issues/5317","id":117372647,"user":{"login":"sebv","id":418288,"avatar_url":"https://avatars.githubusercontent.com/u/418288?v=3","gravatar_id":"","url":"https://api.github.com/users/sebv","html_url":"https://github.com/sebv","followers_url":"https://api.github.com/users/sebv/followers","following_url":"https://api.github.com/users/sebv/following{/other_user}","gists_url":"https://api.github.com/users/sebv/gists{/gist_id}","starred_url":"https://api.github.com/users/sebv/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sebv/subscriptions","organizations_url":"https://api.github.com/users/sebv/orgs","repos_url":"https://api.github.com/users/sebv/repos","events_url":"https://api.github.com/users/sebv/events{/privacy}","received_events_url":"https://api.github.com/users/sebv/received_events","type":"User","site_admin":false},"created_at":"2015-06-30T23:35:25Z","updated_at":"2015-06-30T23:35:25Z","body":"@jlipps https://github.com/npm/node-semver#caret-ranges-123-025-004"}}