Enable only non-deprecated linter with enable-all

[sanposhiho]

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

Now, enable-all enable all linters including deprecated linter.

[kenseinakada] /Users/kenseinakada/workspace/website-server
(*;-;)? < golangci-lint version                           
golangci-lint has version v1.40.0 built from (unknown, mod sum: "h1:MFueiIIh9Ri5yWLRu9RkrS0nd2F+x67zC7ISQR2Hta4=") on (unknown)

~/workspace/website-server master

[kenseinakada] /Users/kenseinakada/workspace/website-server
(*'-') < golangci-lint run ./... --enable-all --no-config
WARN [runner] The linter 'scopelint' is deprecated (since v1.39.0) due to: The repository of the linter has been deprecated by the owner.  Replaced by exportloopref. 
WARN [runner] The linter 'interfacer' is deprecated (since v1.38.0) due to: The repository of the linter has been archived by the owner.  
WARN [runner] The linter 'maligned' is deprecated (since v1.38.0) due to: The repository of the linter has been archived by the owner.  Replaced by govet 'fieldalignment'. 

# result

Describe the solution you'd like

If we want to avoid deprecated linter, we need to disable them using -disable
It is proposed to change the specification of deprecated linter to not be enabled by enable-all.

Describe alternatives you've considered

add a disable-deprecated option to automatically disable all deprecated linter

Additional context
(Yeah, I know that there is a discussion on whether to deprecate the enable-all option in #1888 :))

[ldez]

The deprecation cycle required user interaction, because the user should be aware of the deprecation.

Then we cannot automatically hide the deprecation, the user should know that he has to use another linter.

An option disable-deprecated is also a problem: the set of linters when you set the option will change over time.
Then you will not be aware that a linter should be replaced.

Also enable-all is always used with disable in a production environment and a configuration file, so for me, the use-case is at best a small edge-case or just a theoretical case.

The deprecation cycle can be discussed (when we drop a linter), but personally, I'm against adding an option to disable deprecated linters or to correlate enable-all with this kind of behavior.

[sanposhiho]

Then we cannot automatically hide the deprecation, the user should know that he has to use another linter.

Then you will not be aware that a linter should be replaced.

Hmm, I see. I hadn't thought that far ahead. Thanks

The deprecation cycle can be discussed (when we drop a linter)

If we are designing the deprecation cycle to drop deprecated linters finally, this proposal may not be necessary.

But, if not, 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, which is a bit inconvenient for them, I think. (This is because the number of deprecated linters is expected to increase in the future. )

[ldez]

I would like to propose to close this issue and open another to discuss the deprecation cycle, WDYT?

[sanposhiho]

Okey, Thank you 👍