Should I deprecate old version and add new version for depguard?

[dixonwille]

For backwards compatibility this makes sense.

DepguardV2 is now using the analysis package. v1 was not since it was not available on initial write. There were other other assumptions being made in v1 while golangci-lint was in v1.4, that are no longer the case and was causing issues. So I decided to start a v2 and introduce breaking changes (mainly in how it is configured).

Another note, is it worth it, I noticed gomodguard is a thing which is more efficient as it only reads mod files, where depguard reads every go file being linted (albeit only the imports). I believe they are two different cases (one is for the whole module and depguard is more concerned about package level requirements).

Is there any documentation on how to mark a linter as deprcated if I do go down this route?

[dixonwille]

#1987 I did find this on deprecation, but still unclear as a maintainer of a linter, what I should do.

[ldez]

Hello,

the breaking changes inside linter are allowed because it's impossible to create a major version each time when a linter breaks something, but we always try to minimize the breaking.

I don't know the exact scope of the changes inside depguard, I will spend some time on that, so for now, I don't know what is the best approach.
Maybe you can create a PR that replaces v1 with v2, and we will discuss the best approach inside the PR.

[ldez]

I found a typo OpenPeeDeeP/depguard#44

I tried to create a compatibility layer but it seems impossible because glob seems not supported as a package name and the new Files field is the opposite of IgnoreFileRules.

master...ldez:golangci-lint:feat/depguard-compatibility

[dixonwille]

Yeah, the breaking change was because the configs changed so drastically. I'll see if there is more I can do to potentially add some of those features back in.

Random thought though, if there is a way to have compatability between most of the configs, but only a few features couldn't be, could/should we try importing both? Use the new one for configs that do work and for the ones that don't, throw a warning to the user? Kind of inches them towards using the newer one or upgrading overtime to it. Maintance does go up though, and a tool this size may not want to keep up with that...

[ldez]

I think we will just detect the use of the old configuration and send a warning.
We will keep only one working implementation.