Docs: Add semantic versioning policy (fixes #6244)

README.md

@@ -104,6 +104,30 @@ Before filing an issue, please be sure to read the guidelines for what you're re
 * [Proposing a Rule Change](http://eslint.org/docs/developer-guide/contributing/rule-changes)
 * [Request a Change](http://eslint.org/docs/developer-guide/contributing/changes)
 
+## Semantic Versioning Policy
+
+ESLint follows [semantic versioning](http://semver.org). However, due to the nature of ESLint as a code quality tool, it's not always clear when a minor or major version bump occurs. To help clarify this for everyone, we've defined the following semantic versioning policy for ESLint:
+
+* Patch release (intended to not break your lint build)
+    * A bug fix in a rule that results in ESLint reporting fewer errors.
+    * A bug fix to the CLI or core (including formatters).
+    * Improvements to documentation.
+    * Non-user-facing changes such as refactoring code, adding, deleting, or modifying tests, and increasing test coverage.
+    * Re-releasing after a failed release (i.e., publishing a release that doesn't work for anyone).
+* Minor release (might break your lint build)
+    * A bug fix in a rule that results in ESLint reporting more errors.
+    * A new rule is created.
+    * A new option to an existing rule is created.
+    * An existing rule is deprecated.
+    * A new CLI capability is created.
+    * New capabilities to the public API are added (new classes, new methods, new arguments to existing methods, etc.).
+    * A new formatter is created.
+* Major release (likely to break your lint build)
+    * `eslint:recommended` is updated.
+    * An existing rule is removed.
+    * An existing formatter is removed.
+    * Part of the public API is removed or changed in an incompatible way.
+
 ## Frequently Asked Questions
 
 ### How is ESLint different from JSHint?

docs/developer-guide/contributing/pull-requests.md

@@ -61,8 +61,8 @@ The first line of the commit message (the summary) must have a specific format.
 The `Tag` is one of the following:
 
 * `Fix` - for a bug fix.
+* `Update` - for a backwards-compatible enhancement or a change to a rule that increases the number of reported problems.
 * `New` - implemented a new feature.
-* `Update` - for a backwards-compatible enhancement.
 * `Breaking` - for a backwards-incompatible enhancement or feature.
 * `Docs` - changes to documentation only.
 * `Build` - changes to build process only.

docs/maintainer-guide/issues.md

@@ -14,7 +14,7 @@ New issues are filed frequently, and how we respond to those issues directly aff
 There are four primary issue categories:
 
 1. **Bug** - something isn't working the way it's expected to work.
-1. **Enhancement** - a change to something that already exists. For instance, adding a new option to an existing rule.
+1. **Enhancement** - a change to something that already exists. For instance, adding a new option to an existing rule or a bug in a rule where fixing it will result in the rule reporting more problems (in this case, use both "Bug" and "Enhancement").
 1. **Feature** - adding something that doesn't already exist. For example, adding a new rule, new formatter, or new command line flag.
 1. **Question** - an inquiry about how something works that won't result in a code change. We'd prefer if people use the mailing list or chatroom for questions, but sometimes they'll open an issue.