Prevent Failures from New Linters in Minor Releases about super-linter HOT 7 CLOSED

Hi @wegmans-alex-beck !

The way we're currently managing super-linter releases is (loosely) based on the Conventional Commits spec. Given a version identifier (vMAJOR.MINOR.PATCH):

• We bump MAJOR on breaking changes only.
• We bump MINOR on new features (example: we add a new linter or a new backward-compatible configuration option).
• We bump PATCH on bugfixes and linter updates.

Conditionally enabling linters based on when we include them is too complex for us to maintain. Also, we're probably not going to change the fact that new linters are enabled by default when we introduce them because that would be a breaking change that we're not considering at the moment.

One could argue that adding a new linter might be considered a (potentially) breaking change, but we decided against that, in the end. The main reason emerged when we started thinking about how to handle dependency updates for linters. For example, what shall we do if a linter that we currently ship with super-linter adds a new check, or includes a bugfix for an existing check that was broken? All these changes are potentially breaking for downstream users. With this in mind, we decided for the strategy I described above.

I would advise using the full version identifier (example: v6.4.0, instead of a partial one (example: v6.4 or v6) for builds where you want to make more reproducible.

from super-linter.

We are all humans, but last times this also happens to me. I think something like stable tag would be a solution.

from super-linter.

What should the stable tag point at?

from super-linter.

What should the stable tag point at?

At the last stable release :) the most stable version, or any point where we can be sure.
Some version where the most of bugs are closed and no breaking features.

from super-linter.

How would we decide what "stable release" means? It's a somewhat vague concept. :)
It could mean different things to different people.

I think we might be overcomplicating this because you can already use a fully qualified version identifier (example: v6.0.0) instead of partial (unstable by definition) ones (v6.0, v6, latest).

My suggestion here is to stick with a fully qualified version identifier that you consider stable/fine/working as you expect/etc. This is what you consider "stable".

Also, I would set appropriate branch protection rules. This would make upgrades less painful, especially if you have any system in place to automatically update (or propose updates) your dependencies, such as DependaBot or Renovate.

from super-linter.

@ferrarimarco

I understand you: not so easy to decide what version is the most stable for all users. I think stable is when you run with defaults, the most bugs are already fixed and no new breaking features added.

So if you would like to suggest something like "this version is the most stable", or "this version is one of the best" I can pin them. But, yes, I can pin a special one instead of the latest. Because sometimes I need to mergre a changes wihtout spending time for examing recently added tools. Let it be 6.4.1 :)

from super-linter.

Thanks for sharing the details of your use case. Perhaps we can close this.

from super-linter.