{"issue":{"created_at":"2011-11-21T12:26:59Z","state":"open","updated_at":"2011-12-09T06:07:57Z","comments":5,"user":{"gravatar_id":"0887991a8846577a6aa85433d6ab3ea2","id":34264,"url":"https://api.github.com/users/laserlemon","avatar_url":"https://secure.gravatar.com/avatar/0887991a8846577a6aa85433d6ab3ea2?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","login":"laserlemon"},"body":"Yanking gems is a necessary evil.\r\n\r\nI don't think there's any good way to prevent authors from prematurely pushing broken or unfinished gems. Unfortunately, yanked gems often leave people's projects in gem dependency limbo. For instance, the good people of @collectiveidea have found their projects depending upon the `gherkin` gem (indirectly through `cucumber`) and the surrounding dependencies are such that `gherkin` is locked down to `~> 2.3.8`. The problem is that the only versions that satisfy that requirement are `2.3.8`, `2.3.9` and `2.3.10`, all of which have been yanked.\r\n\r\nhttp://rubygems.org/gems/gherkin/versions\r\n\r\nWhile scenarios like the one above can't always be avoided, it's important to notify developers when a version is yanked so they can take appropriate actions and I think that the existing web hook functionality is a great way to deliver those notifications.\r\n\r\nIn my mind, the easiest way to pull it off is to hit the same registered web hook URLs rather than registering separate hooks for yanks. So if we were to hit the same URLs, either the method or the payload would have to change in order to differentiate pushes and yanks. I was in favor of an identical DELETE request until I started getting mixed signals on whether DELETE requests can/should have request bodies.\r\n\r\nIf we were to change the web hook payload, I think the existing webhook bodies should stay the same and the new hooks should take on a backwards-incompatible form so that yanked gem versions aren't mistaken for newly pushed gem versions with existing web hook subscribers.\r\n\r\nWhat are your feelings on the concept of yank web hooks and their implementation?","assignee":null,"id":2304118,"pull_request":{"patch_url":"https://github.com/rubygems/rubygems.org/pull/366.patch","html_url":"https://github.com/rubygems/rubygems.org/pull/366","diff_url":"https://github.com/rubygems/rubygems.org/pull/366.diff"},"labels":[{"name":"feature","color":"349429","url":"https://api.github.com/repos/rubygems/rubygems.org/labels/feature"}],"number":366,"title":"Webhooks for yanked gems","closed_at":null,"html_url":"https://github.com/rubygems/rubygems.org/issues/366","url":"https://api.github.com/repos/rubygems/rubygems.org/issues/366","milestone":null},"action":"created","comment":{"created_at":"2011-12-09T06:07:57Z","updated_at":"2011-12-09T06:07:57Z","user":{"gravatar_id":"6a13e655e637138f8d571cec3f9cea76","id":149304,"url":"https://api.github.com/users/jrochkind","avatar_url":"https://secure.gravatar.com/avatar/6a13e655e637138f8d571cec3f9cea76?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","login":"jrochkind"},"body":"Sorry if this is unwelcome, it's not about the actual feature, but instead about the _use case_ for the feature you mention. \r\n\r\nIf Issue #123 were complete, so the reverse dependencies of a gem were known....  rubygems could even automatically identify _which_ gems are effected (at least as a first-level dependency) by a yank, even going so far as to see (using bundler?) if those reverse dependencies are now left in a not-possible-to-resolve-dependencies state as a result of the yank... and rubygems usually knows the contact email address of those reverse dependencies too....\r\n\r\nyou see where that's going. It could actually automatically email authors of gems left in such states by yanks of their dependencies.   Perhaps as an opt-in service to a rubygems.org account, to avoid being spam. ","id":3075869,"url":"https://api.github.com/repos/rubygems/rubygems.org/issues/comments/3075869"}}