Let's discuss about the deprecation of `enable-all`

[ldez]

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

@jirfag in #803 said:

enable-all has the following advantage:

1. convenient for users, I understand it.
2. all newly added linters are automatically used by a lot of users.

But it has the following downside: when golangci-lint is updated users typically get some new linters enabled: it can be annoying, it can fail CI builds. Users should disable linters one by one in such cases.

I think long-term updates cost is more important than a one-time configuration cost.

Let's discuss it!

#803 (comment)

but there was no discussion, the PR was just merged.

Describe the solution you'd like

I would like to open a constructive debate about this deprecation.

Describe alternatives you've considered

Removes the deprecation of enable-all.

Additional context

#1686

[frederikhors]

I agree with you and I opened #1887 because I don't know how to auto-update (not manually, error-prone) new linters in my config.

[ldez]

I think that the deprecation was related to GolangCI service and CI.

GolangCI service is down.

Now, the problem with enable-all is for people that use latest in their CI because locally I think there is no real problem.

IMO the real bad practice is to use latest in a CI, I think most of us know this sentence: friends don't let friends use latest.

So I think we have to document this bad practice instead of deprecating enable-all.

[ldez]

Also the linters them-self evolve and can either introduce new rules or update their rules.
Then even if you enable only some linters you still have a possibility to break your CI.
enable-all is just a specific case of this problem.

So IMO, the solution is still the same: don't use latest in a CI and use an explicit version of the tools that run in a CI.

[ldez]

From what I can see in #803, #1686, and this issue, nobody seems to want the removal of enable-all.

Maybe I am missing some use-cases, so please express your voice if you have a use-case that can justify this removal.

We will wait, for the moment I don't know how long, but we will take the time for the debate.

[frederikhors]

In my day to day work I need something warns me about mistakes. If I upgrade it I trust that something has changed for the better and that more mistakes of mine can be detected.

If I know that I don't care about some linter I can comment out it in my config.yml.

Am I wrong in thinking like this?

[butuzov]

Oh... please not. I can't dedicate much time to development (in last two months at least), and having enable-all is saving me time to check what's are new linters and their settings once the new version released, and not tracking each merged pr or setting in code.

[ldez]

@butuzov enable-all is deprecated since 2019 -> #803

This issue is to discuss and maybe remove this deprecation instead of removing enable-all.

[butuzov]

Sorry, i am OK to remove deprecation. Not the other way..