{"action":"created","issue":{"url":"https://api.github.com/repos/yarnpkg/yarn/issues/2316","repository_url":"https://api.github.com/repos/yarnpkg/yarn","labels_url":"https://api.github.com/repos/yarnpkg/yarn/issues/2316/labels{/name}","comments_url":"https://api.github.com/repos/yarnpkg/yarn/issues/2316/comments","events_url":"https://api.github.com/repos/yarnpkg/yarn/issues/2316/events","html_url":"https://github.com/yarnpkg/yarn/issues/2316","id":197019884,"number":2316,"title":"Yarn Should Stop Using Version Ranges for Dependencies","user":{"login":"thefringeninja","id":495495,"avatar_url":"https://avatars.githubusercontent.com/u/495495?v=3","gravatar_id":"","url":"https://api.github.com/users/thefringeninja","html_url":"https://github.com/thefringeninja","followers_url":"https://api.github.com/users/thefringeninja/followers","following_url":"https://api.github.com/users/thefringeninja/following{/other_user}","gists_url":"https://api.github.com/users/thefringeninja/gists{/gist_id}","starred_url":"https://api.github.com/users/thefringeninja/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/thefringeninja/subscriptions","organizations_url":"https://api.github.com/users/thefringeninja/orgs","repos_url":"https://api.github.com/users/thefringeninja/repos","events_url":"https://api.github.com/users/thefringeninja/events{/privacy}","received_events_url":"https://api.github.com/users/thefringeninja/received_events","type":"User","site_admin":false},"labels":[{"id":461730541,"url":"https://api.github.com/repos/yarnpkg/yarn/labels/needs%20triage","name":"needs triage","color":"c5def5","default":false}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":6,"created_at":"2016-12-21T20:00:03Z","updated_at":"2016-12-22T01:37:05Z","closed_at":null,"body":"**Do you want to request a *feature* or report a *bug*?**\r\nBug\r\n\r\n**What is the current behavior?**\r\n\r\nFor whatever reason, far too many node.js developers do not actually follow semantic versioning when updating packages. Consequently, three times now, when a maintainer of one of yarn's dependencies has updated a package, it has broken our continuous integrations builds. As in yarn fails to restore packages.\r\n\r\nFor this reason, in our own builds, we only depend on exact package versions in our root `package.json`. To do otherwise would fly in the face of repeatability. [A lot can go wrong without it](https://en.wikipedia.org/wiki/Knight_Capital_Group#2012_stock_trading_disruption). I realize that implementing this here won't do a whole lot to fix the wider problem. OTOH, a package manager is pretty critical."},"comment":{"url":"https://api.github.com/repos/yarnpkg/yarn/issues/comments/268695686","html_url":"https://github.com/yarnpkg/yarn/issues/2316#issuecomment-268695686","issue_url":"https://api.github.com/repos/yarnpkg/yarn/issues/2316","id":268695686,"user":{"login":"Daniel15","id":91933,"avatar_url":"https://avatars.githubusercontent.com/u/91933?v=3","gravatar_id":"","url":"https://api.github.com/users/Daniel15","html_url":"https://github.com/Daniel15","followers_url":"https://api.github.com/users/Daniel15/followers","following_url":"https://api.github.com/users/Daniel15/following{/other_user}","gists_url":"https://api.github.com/users/Daniel15/gists{/gist_id}","starred_url":"https://api.github.com/users/Daniel15/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Daniel15/subscriptions","organizations_url":"https://api.github.com/users/Daniel15/orgs","repos_url":"https://api.github.com/users/Daniel15/repos","events_url":"https://api.github.com/users/Daniel15/events{/privacy}","received_events_url":"https://api.github.com/users/Daniel15/received_events","type":"User","site_admin":false},"created_at":"2016-12-22T01:37:05Z","updated_at":"2016-12-22T01:37:05Z","body":"@thefringeninja Yeah, you could do whatever you like with the tarball 😃  . The latest tarball is available at https://yarnpkg.com/latest.tar.gz, and its GPG signature is at https://yarnpkg.com/latest.tar.gz.asc (you probably saw this in the install script).  For a build server, I'd suggest locking down the Yarn version. You can get the tarball for a specific version using a URL like https://yarnpkg.com/downloads/0.18.1/yarn-v0.18.1.tar.gz (or the `--version` flag for the installation script).\r\n\r\nYou could just extract it locally somewhere - Just `wget` it and extract with `tar`. If you want to be really awesome, you could modify the installation script to add an optional flag that would allow the installation directory to be specified (ie. something like `./install.sh --version 0.18.1 --destination /opt/yarn-0.18.1/`). If you do go that way, we'd love a pull request to update it. The installation script lives in the website repo.\r\n\r\n> Our organization has multiple teams using a shared CI infrastructure (TeamCity). We want deterministic builds, so the only way to do that is to force all teams to use the same version of yarn.\r\n\r\nOne other option is to install Yarn on your build servers, and your builds could simply rely on it being preinstalled. I guess this depends on how your build servers are configured (ie. manually, or via Chef, or something else) and whether your sysadmins would be okay with that. If your build servers are running Ubuntu or Debian, the Yarn package should work well in this case."}}
{"actor":{"display_login":"Daniel15"}}