{"action":"created","issue":{"url":"https://api.github.com/repos/eslint/eslint/issues/5845","repository_url":"https://api.github.com/repos/eslint/eslint","labels_url":"https://api.github.com/repos/eslint/eslint/issues/5845/labels{/name}","comments_url":"https://api.github.com/repos/eslint/eslint/issues/5845/comments","events_url":"https://api.github.com/repos/eslint/eslint/issues/5845/events","html_url":"https://github.com/eslint/eslint/issues/5845","id":148200805,"number":5845,"title":"Proposal for deprecating rules","user":{"login":"nzakas","id":38546,"avatar_url":"https://avatars.githubusercontent.com/u/38546?v=3","gravatar_id":"","url":"https://api.github.com/users/nzakas","html_url":"https://github.com/nzakas","followers_url":"https://api.github.com/users/nzakas/followers","following_url":"https://api.github.com/users/nzakas/following{/other_user}","gists_url":"https://api.github.com/users/nzakas/gists{/gist_id}","starred_url":"https://api.github.com/users/nzakas/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/nzakas/subscriptions","organizations_url":"https://api.github.com/users/nzakas/orgs","repos_url":"https://api.github.com/users/nzakas/repos","events_url":"https://api.github.com/users/nzakas/events{/privacy}","received_events_url":"https://api.github.com/users/nzakas/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/eslint/eslint/labels/needs%20bikeshedding","name":"needs bikeshedding","color":"f7c6c7"}],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":24,"created_at":"2016-04-13T22:26:57Z","updated_at":"2016-04-18T21:11:17Z","closed_at":null,"body":"## Background\r\n\r\nESLint has a long, depressing history of removing old rules. We did this a lot pre-1.0.0, probably longer after we should have. We stopped doing that outside of major releases after 1.0.0, which means we removed a bunch of rules in 2.0.0 as well. We rationalized this as important to keep the code base clean and we always replaced removed rules with better alternatives. We figured people could just update their configs one time and that would fine.\r\n\r\n## Problems\r\n\r\nNow that ESLint is as popular tool, it's more important than ever that we do not break existing installations. We need to remember that whenever we're asking someone to update their config file because we removed a rule that they are doing so not just in one file, but in many, possibly hundreds of files if they use ESLint in multiple projects. That also means every shared config they rely on must be updated as well, and further means that shared configs depend very heavily on the version of ESLint they are used with.\r\n\r\nThat's a lot of pain distributed across millions of installations all to save us some pain in maintenance, and I think we're at the point where that equation is horrifically unbalanced.\r\n\r\n## Proposal\r\n\r\nWhat I'd like to propose going forward is:\r\n\r\n* We **never** remove old rules under any circumstances.\r\n* Instead, we deprecates rules that we believe people shouldn't use anymore. When a rule is deprecated, it means:\r\n  1. The rule is moved to the \"deprecated\" page (maybe eslint.org/docs/rules/deprecated/) instead of being on the main page.\r\n  1. We label the rule as deprecated on the rule's documentation page.\r\n  1. We no longer do **any** work on the rule. No bug fixes, no enhancements, no documentation updates (except for website formatting changes to coincide with other design changes). Any requests are automatically closed with a message to use the replacement rule(s) instead.\r\n\r\nMaybe we could do some other things as well, I'm open to suggestions. I just think the main thing is that we need to keep rules around, deprecate them, and stop all work on them.\r\n\r\n\r\nThoughts? @eslint/eslint-team \r\n\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/eslint/eslint/issues/comments/211579358","html_url":"https://github.com/eslint/eslint/issues/5845#issuecomment-211579358","issue_url":"https://api.github.com/repos/eslint/eslint/issues/5845","id":211579358,"user":{"login":"alberto","id":72561,"avatar_url":"https://avatars.githubusercontent.com/u/72561?v=3","gravatar_id":"","url":"https://api.github.com/users/alberto","html_url":"https://github.com/alberto","followers_url":"https://api.github.com/users/alberto/followers","following_url":"https://api.github.com/users/alberto/following{/other_user}","gists_url":"https://api.github.com/users/alberto/gists{/gist_id}","starred_url":"https://api.github.com/users/alberto/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/alberto/subscriptions","organizations_url":"https://api.github.com/users/alberto/orgs","repos_url":"https://api.github.com/users/alberto/repos","events_url":"https://api.github.com/users/alberto/events{/privacy}","received_events_url":"https://api.github.com/users/alberto/received_events","type":"User","site_admin":false},"created_at":"2016-04-18T21:11:17Z","updated_at":"2016-04-18T21:11:17Z","body":"@nzakas I don't want to get too argumentative, so feel free to ignore the responses below, but since you were asking for feedback, you could keep the discussion open a little longer before discarding ideas as unrealistic :)\r\n\r\n> We can't actually do this for a few reasons. First, plugins always have prefixes, so not only would people have to download the package, they would still have to update their config files, which is exactly the pain I was looking to avoid with this proposal.\r\n\r\nCouldn't it be feasible to make an exception for our `eslint-plugin-deprecated-rules` package so that they didn't need to be prefixed? Then one would only have to include that.\r\n\r\n>  Second, we'd still need to keep the documentation for deprecated rules along with all the other rules, so separating that out would also cause confusion.\r\n\r\nI don't see why they couldn't be still be generated on our website.\r\n\r\n> This is not what I am saying. First, major releases are not strictly tied to rules, we can have other breaking changes that would require a major release (such as dropping support for Node < 4). And again, it's not that people will be surprised about breaking changes, I don't really care how surprised people are, what I care about is the pain people feel as a result of breaking changes. Needing to update every config file they have across dozens of repositories is a significant pain. Also, we don't have to get things right the first time. We can always deprecate a rule we get wrong and replace it with something else. The difference is that we are not penalizing all of our users because we made a mistake.\r\n\r\nHere I was thinking also about breaking changes in options too. The proposal is centered in deprecating rules but the underlying one is (correct me if I am wrong) \"don't do anything that would cause end users to have to update their configs\".\r\n\r\nI think we should allow ourselves to fix our stuff and do some cleanup once in a while. I agree we should limit that, and I'm ok with one year or whatever we agree is reasonable."}}