Release strategy

[chavacava]

Currently there is no clear release strategy for revive. In fact there is no strategy at all.
It could be interesting to clearly define what are releasing triggers (specific dates, every n months/weeks, when need to release a fix for a major/blocking bug, every n fix/features, ... in synchro with golangci-lint ?)

[alexandear]

Thanks for raising this.

As Revive is non-profit, maintained in our spare time, and not tied to external dependencies, we have some flexibility in how we release.

I'd propose the following approach:

• Minor release. After adding ~2–3 new rules, or once a month if only one rule was added, or every 6 months at minimum (to bump supported Go versions).
• Patch release. Within 1–2 weeks after a minor release if fixes are needed (no new features/PRs merged in the meantime.
• Major release (v2). Once we have time or desire to address most of the open items in Roadmap: Revive v2 major release #1391.

As a next step, we can extend the documentation for maintainers to clarify the release process.
A few references:

• https://github.com/go-gitea/gitea/blob/main/CONTRIBUTING.md#release-cycle
• https://github.com/containers/podman/blob/68b687648177cbe8df03df22f4fe1f5602abbb31/RELEASE_PROCESS.md?plain=1#L1

[mgechev]

+1 to @alexandear's proposal. Releasing after we ship a certain amount of features or fixes makes sense.

In Angular we have time-based releases to help enterprises prepare and plan. This allows them to allocate resources when we ship a major to update to the latest changes. We also have a good amount of people working on the framework.

Given Revive is not backed by a company and is a static analysis tool, publishing releases when we stack up enough changes sounds right.

[alexandear]

I think we should mention "Release strategy" in the docs.