have discuss about versioning to follow Semantic Versioning 2.0.0

[sanposhiho]

your feature request related to a problem? Please describe.

Hello team.

On golangci-lint, users can run linters with almost the same usability -- the same configuration, the same issue they taught, etc.

A developer of a linter on golangci-lint adds super-braking change on his/her linter and he/she up major version of the linter, dependabot tells us the release and we merge (maybe with fixing of test).
Currently, we add these major-version-up changes on minor version up of golangci-lint. (example: #1947)
So, users will face these changes with minor version up of golangci-lint.

Shouldn't we up major version when some braking changes are added on linter(= when major version up on linter)?
And because of a similar reason, I think we should not add linters whose version hasn't reached v1.

---

Sorry if this issue has already been discussed somewhere.

This issue may be related to #1987.

Describe the solution you'd like.

• when we up major versions of linter, we up major version of golangci-lint.
• we don't add linters whose version hasn't reached v1.

Describe alternatives you've considered.

I don't have it now. Let's discuss.

Additional context

(As you know, we should follow Semantic Versioning 2.0.0.)
https://golang.org/ref/mod#versions
https://semver.org/

[ldez]

Hello,

I think that the discussion has been already done about that, but I don't know where.

I'm against correlate major/breaking versions of the linters and major versions of golangci-lint.

• some linters don't have a version (we use pseudo-version)
• some linters are in v0 and are legit to do that (then breaking changes is allowed and we don't have to put a constraint on that)
• a major version of a linter doesn't mean a breaking change of the configuration (it can be just an API change)
• the major version system in Go lakes of tooling
• we will have a lot of major versions but without real changes, and this will be a constraint for the user more than us

The semver from the point of view of golangci-lint is not based on linters configuration, but on golangci-lint core configuration.
golangci-lint is a kind of motor/engine.

For me, golangci-lint already follows semver.

[SVilgelm]

I agree with @ldez, the major version of the golangci-lint is totally unrelated to the versions of the linters.
And from my experience, the breaking changes are usually very simple in fixing, even in huge projects.
I'm alway check what is new in the new versions of goalngci-lint and update the version manually on local system or on CI

[sanposhiho]

The semver from the point of view of golangci-lint is not based on linters configuration, but on golangci-lint core configuration.
golangci-lint is a kind of motor/engine.

convinced with this -- golangci-lint is linter runner but not linters itself, so we don't have to manage changes on linters with golangci-lint version.

---

Are there ways for users to know versions of linters on golangci-lint? (without seeing go.mod)
I think it would be better to create a way for users to easily know versions of linters, because we don't correlate major/breaking versions of the linters and major versions of golangci-lint.
For example, add versions of linters on linters page, or show versions with golangci-lint linters command.
With it, we can make users more aware of the version of linters itself.

What do you think?

[ldez]

The majority of the linters doesn't have a changelog to follow configuration changes, then I'm not sure if it's useful to display linters version.

FYI, I am able to do that automatically:

[bombsimon]

I agree with @ldez and @SVilgelm, it would not make sense to me to update major version of golangci-lint that often. I also remember having these discussions and I remember we talked about why golangci-lint has such a small public API and is hard to run from code, basically because we want to be able to do big changes without having to update the major version.

[sanposhiho]

The majority of the linters doesn't have a changelog

Hm, definitely.
I thought some users may want to check if the linter is reached v1 or not to select linters, but maybe we don't need to increase the amount of information on the linter page just because of that.

what do you think?

[sanposhiho]

Close it, thanks