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

🐛 Bugs

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

See Bugs

Versioning Policy

golangci-lint follows semantic versioning. 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 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.