Versioning of named linter groups ('builtinLinters' option)

[fredemmott]

Should a user be able to say "I started using HHAST at vx.y, don't give me any new errors even when I upgrade?"

--

Should users be able to provide separate version constraints for different categories of linters?

--

What if a bug is fixed in a linter and it now finds more cases of the same problem?

[fredemmott]

Tying into lexidor's comment at #423 :

Should we have minimum and maximum versions?

For example, if I want fb-style: 4.133, does that mean I require 4.133, or I permit any linter up to and including the 4.133 set?

Do I need to be able to explicitly say "fb-style 4.130 or above is required, but anything up to 4.133 is ok"?

--

I think the lower bound is implied by the overall hhast version constraint and CI environment, and we don't need a separate setting/constraint: if you permit hhast 4.130 and fb-style 4.133, that implies that you're OK with 4.130 doing the best it can.

i.e., the version constraint here is a maximum, not a minimum

[lexidor]

I believe there is a good reason to allow for a minimum version. If a buggy linter is introduced and later fixed, you want to exclude the buggy version of this linter. This is it a constraint in the composer sense (exits with a failed exit code if unmet), but a gentle way to tell hhast to skip this buggy linter.

[fredemmott]

If we distinguish at a configuration level between linters and groups, is that needed for groups, or just specific linters?

[lexidor]

fb-style: "4.133", DontAwaitInALoopLinter: "<4.90".

[lexidor]

Minimum versions on groups are indeed far less useful. Having this be a per linter only thing wouldn't be that bad.

[fredemmott]

Should a user be able to say "I started using HHAST at vx.y, don't give me any new errors even when I upgrade?"

What if a bug is fixed in a linter and it now finds more cases of the same problem?

I think we should consider this acceptable, out of practicality or nothing else: otherwise we need to maintain bug-for-bug compatibility and versioning within a linter.

In other words, we need to interpret version constraints as saying "I'm interested in this class of errors", rather than "I only want the same exact same error instances reported that HHAST x.y did"