---
title: Roadmap
---

## 💡 Feature Requests

Please file an issue to suggest new features. Vote on feature requests by adding a 👍. This helps maintainers prioritize what to work on.

[See Feature Requests](https://github.com/golangci/golangci-lint/issues?utf8=✓&q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc+label%3Aenhancement)

## 🐛 Bugs

Please file an issue for bugs, missing documentation, or unexpected behavior.

[See Bugs](https://github.com/golangci/golangci-lint/issues?utf8=✓&q=is%3Aissue+is%3Aopen+label%3A%22bug%22+sort%3Acreated-desc)

## Versioning Policy

`golangci-lint` follows [semantic versioning](https://semver.org). However, due to the nature of `golangci-lint` 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:

- Patch release (intended to not break your lint build)
- A patch version update in a specific linter that results in `golangci-lint` reporting fewer errors.
- A bug fix to the CLI or core (packages loading, runner, postprocessors, etc).
- 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 because of newly found issues)
- A major or minor version update of a specific linter that results in `golangci-lint` reporting more errors.
- A new linter is added.
- An existing configuration option or linter is deprecated.
- A new CLI command is created.
- Backward incompatible change of configuration with extremely low impact, e.g. adding validation of a list of enabled `go-critic` checkers.
- Major release (likely to break your lint build)
- Backward incompatible change of configuration with huge impact, e.g. removing excluding issues about missed comments from `golint` by default.
- A linter 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 fixed minor version and fixed or the latest patch version to guarantee the results of your builds.

For example, in our [GitHub Action](https://github.com/golangci/golangci-lint-action) we require users to explicitly set the minor version of `golangci-lint`
and we always use the latest patch version.

## Linter Deprecation Cycle

A linter can be deprecated for various reasons, e.g. the linter stops working with a newer version of Go or the author has abandoned its linter.

The deprecation of a linter will follow 3 phases:

1. **Display of a warning message**: The linter can still be used (unless it's completely non-functional),
  but it's recommended to remove it from your configuration.
2. **Display of an error message**: At this point, you should remove the linter.
  The original implementation is replaced by a placeholder that does nothing.
  The linter is NOT enabled when using `enable-all` and should be removed from the `disable` option.
3. **Removal of the linter** from golangci-lint.

Each phase corresponds to a minor version:

- v1.0.0 -> warning message
- v1.1.0 -> error message
- v1.2.0 -> linter removed

The deprecated linters are removed from presets immediately when they are deprecated (phase 1).

We will provide clear information about those changes on different supports: changelog, logs, social network, etc.

We consider the removal of a linter as non-breaking changes for golangci-lint itself.
No major version will be created when a linter is removed.

## Future Plans

1. Upstream all changes of forked linters.
2. Make it easy to write own linter/checker: it should take a minimum code, have perfect documentation, debugging and testing tooling.
3. Speed up SSA loading: on-disk cache and existing code profiling-optimizing.
4. Analyze (don't only filter) only new code: analyze only changed files and dependencies, make incremental analysis, caches.
5. Smart new issues detector: don't print existing issues on changed lines.
6. Minimize false-positives by fixing linters and improving testing tooling.
7. Automatic issues fixing (code rewrite, refactoring) where it's possible.
8. Documentation for every issue type.
