Skip to content

discuss about design deprecation cycle (how to handle deprecated linter) #1987

Closed
@sanposhiho

Description

@sanposhiho

Is your feature request related to a problem? Please describe.

Now, Some linters have been deprecated on golangci-lint.
Golangci-lint send out a warn message to users who are using deprecated linter, telling them that it is deprecated.

The number of deprecated linters is expected to increase in the future.
We need to discuss how to handle deprecated linter.

Describe the solution you'd like

  • It will be deprecated for a while and then removed from golangci-lint?
  • For users who want to use a deprecated linter for some reason, leave it deprecated and leave it in golangci instead of deleting it?
  • Create new status like deleted, separate from deprecated?
  • (Other opinions are welcome)

Additional context

had a small discussion on #1986 about how to handle deprecated linter when the enable-all is specified

  • If enable-all automatically avoids deprecated linter, existing users will not be able to notice that the linter they were using through enable-all has been deprecated.
  • But, from the point of view of new golangci-lint users, in order to avoid using deprecated linters, they need to use enable-all with many disable options.
    • This concern may not be necessary if deprecated linters will be removed from Golangci-lint finally. (This is because users only need to disable the linter that has been recently deprecated and has not yet been removed from golangci.)

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or improvement

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions