Add semantic version policy
ntwb opened this issue · comments
Draft text:
## Semantic Versioning Policy
stylelint-config-wordpress follows [semantic versioning](http://semver.org). However, due to the nature of stylelint as a code quality tool, it's not always clear when a minor or major version bump occurs. To help clarify this for everyone, based on stylelint's [semantic versioning policy](https://github.com/stylelint/stylelint#semantic-versioning-policy) which is in turn based on ESLint's [semantic versioning policy](https://github.com/eslint/eslint#semantic-versioning-policy), we've defined the following subset of stylelint's semantic versioning policy for stylelint-config-wordpress:
- Patch release (intended to not break your lint build)
- A bug fix in a rule that results in stylelint reporting fewer errors.
- 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 stylelint reporting more errors.
- A new rule is added.
- A new option to an existing rule that does not result in stylelint reporting more errors by default.
- An existing rule is deprecated.
- Major release (likely to break your lint build)
- A change in the documented behaviour of an existing rule results in stylelint reporting more errors by default.
- An existing rule is removed.
According to our policy, any minor update may report more errors than the previous release (ex: from a bug fix). As such, we recommend using the tilde (`~`) in `package.json` e.g. `"stylelint": "~7.2.0"` to guarantee the results of your builds.
The above is taken from the upcoming stylelint v8 semver policy and needs reviewing
Closing per stylelint/stylelint-config-standard#86 (comment)