Document versioning policy in readme

[markelog]

Is your feature request related to a problem? Please describe.
Newest patch release introduced changes to the G601 rule logic. Now it notices more errors than it had before. Which means that just by bumping the patch version (in my setup it happens automatically) it will show errors for the code that hasn't changed

Describe the solution you'd like
I would like you to consider changing the release practise to adhere to a more strict release policy. Like some other linters have done. See eslint docs as a reference - https://github.com/eslint/eslint#semantic-versioning-policy

[ernado]

Are you talking about v1.27.0?
It is a minor version bump, so we can introduce more checks for linters.

I've used to bump patch versions instead of minor while stabilizing the project, but now a minor version should be increased if new linter is introduced or updated (except some bugfix).

TLDR: we are trying to use same policy, but past releases were more chaotic due to project status, now it should be better

[markelog]

Are you talking about v1.27.0?

Yeah!

TLDR: we are trying to use same policy, but past releases were more chaotic due to project status, now it should be better

Nice! Should we document it some of it somewhere?

[ernado]

Yeah!

But it is a minor version update and follows eslint policy, doesn't it?

[markelog]

Yes, sorry I was confused for a second :)

[ernado]

Nice! Should we document it some of it somewhere?

Sure, we will do this, but no ETA for now.

UPD: Anyway I'll be stricter for patch version bump starting from v1.27

[jirfag]

Hi,
I'll document it, I agree that it's important.

[theckman]

Have we discussed the side effects of Semantic Import Versioning and leaning in to more major releases? This is going to be a PITA for anyone who consumes this as a dependency in their project, and I suspect it'll incur overhead on us too as we'll need to bump all of our self-referencing import statements whenever we do that.

I ask, because if we follow their policy we may have violated this (which they use for major bumps):

A new option to an existing rule that results in ESLint reporting more errors by default.

[jirfag]

@theckman it's the good point, I'm going to document it in this way:

Versioning Policy

golangci-lint follows semantic versioning. However, due to the nature of golangci-lint as a code quality tool,
it's not always clear when a minor or major version bump occurs. To help clarify this for everyone, we've defined the following semantic versioning policy:

• Patch release (intended to not break your lint build)
  • A patch version update in a specific linter that results in golangci-lint reporting fewer errors.
  • A bug fix to the CLI or core (packages loading, runner, postprocessors, etc).
  • Improvements to documentation.
  • Non-user-facing changes such as refactoring code, adding, deleting, or modifying tests, and increasing test coverage.
  • Re-releasing after a failed release (i.e., publishing a release that doesn't work for anyone).
• Minor release (might break your lint build because of newly found issues)
  • A major or minor version update of a specific linter that results in golangci-lint reporting more errors.
  • A new linter is added.
  • An existing configuration option or linter is deprecated.
  • A new CLI command is created.
  • Backward incompatible change of configuration with extremely low impact, e.g. adding validation of a list of enabled go-critic checkers.
• Major release (likely to break your lint build)
  • Backward incompatible change of configuration with huge impact, e.g. removing excluding issues about missed comments from golint by default.
  • A linter is removed.

According to our policy, any minor update may report more errors than the previous release (ex: from a bug fix).
As such, we recommend using the fixed minor version and fixed or the latest patch version to guarantee the results of your builds.

For example, in our GitHub Action we require users to explicitly set the minor version of golangci-lint
and we always use the latest patch version.

---

What do you think?
/cc @golangci/core-team

[ernado]

LGTM

A new option to an existing rule that results in ESLint reporting more errors by default.

Typo :)

[jirfag]

@ernado thank you, I've fixed

[jirfag]

I've published the policy into the website, but not closing the issue until hearing more feedback,
maybe we can improve this policy.

[bombsimon]

Clear and concise, looks good!

[markelog]

Awesome :)

[theckman]

@jirfag since golangci-lint can also be consumed as a library (I had to write a wrapper), should we also extend our major section to include breaking changes of non-internal Go packages? If we would like to add this I'd suggest we also include an exception, for changes needed to fix a security issue qualifying as a minor release. This would make it similar to the Go 1.x API compatibility guarantee.

I suspect it was probably implied for us, but wasn't sure if there's benefit in being overly explicit.

[bombsimon]

Personally I think it's implied and clear enough. If a breaking change in the API didn't bump major version we wouldn't follow semantic versioning which is the very first thing stated.

[jirfag]

I didn't think that anyone uses it as a library. Could you share your use-case?

[bombsimon]

I think theckman/golangci-lint-emacs must be the one @theckman is referring to. It seems like it only uses NewExecutor() and a value for proper exit code.

[theckman]

@jirfag the thing that made me raise #1043, the project @bombsimon linked to.

Jank to make my editor experience better.

[jirfag]

got it,
I think we should migrate everything except a few interfaces like commands to internal/ and only after that, we can guarantee stable interfaces. Currently, a lot of exported interfaces in pkg/ can be changed in any release.

[jirfag]

looks like we can close it