consider bumping pedantic by major versions when adding a lint about pedantic

[davidmorgan]

There's actually a nasty problem here :/ ... because we have conflated the analysis options with the tiny amount of code in lib/pedantic.dart.

dev_dependencies are not a problem, but anyone using unawaited needs a normal dependency. If two packages both use unawaited, and want different pinned versions of lints, then they can't be used together. They will be forced to move to the same version of the lints, first.

Here's one possible solution. We could include all versions of the analysis options in the package:

lib/analysis_options.1.2.0.yaml
lib/analysis_options.1.3.0.yaml
lib/analysis_options.1.4.0.yaml

then, also include an analysis_options.yaml file that points to the latest version. So for most people behaviour is unchanged. If you want to pin your analysis options version, you do that by including a specific yaml file; it's no longer anything to do with pub.

What do you think?

[a14n]

An other option would be to publish an other package containing only the yaml file.

• pedantic for unawaited...
• pedantic_yaml (or something else) for analysis_options.yaml - this package will be used exclusively in dev_dependencies and every change can be released by bumping its major version.

[davidmorgan]

Yes. I'm not a huge fan of the idea, partly because of overhead in migrating to and maintaining an additional package, and partly because the yaml files don't really seem to fit with pub: they're not dart code, and every new version is incompatible.

But it would solve the problem :)

[devoncarew]

Having versioned sets of analysis options files seems great - it would let projects pin on specific versions, and migrate to new ones as they wanted to.

[grouma]

I'll be a voice in the other direction on this one. It's definitely annoying that changes to package:pedantic can break our packages. However, these breaks are often trivial to fix and are a good alert that there is a new standard to adopt. I don't see us actively upgrading to the newer lints otherwise. If we really want to enable users to pin to a version I suggest providing lib/analysis_options.latest.yaml or something.

edit

Looks like the linked PR keeps the latest version under lib/analysis_options.yaml so there is no need for lib/analysis_options.latest.yaml.

[pq]

One reason not to pin versions is if you care about your pana scoring. I'm guessing there you'll always be graded on latest? (@jonasfj?)

Awareness of new rules is a known, acute but as of yet unsolved problem. 😬 (See also: dart-lang/linter#1390.)

[jakemac53]

+1 for providing versioned files with the regular analysis_options.yaml as an alias for the latest one.

That allows you to keep up with the latest lints, while also providing a low friction path to temporarily pinning to a previous version if you don't have time to update immediately when you get broken by the new lints.

[davidmorgan]

Thanks for the input everyone. Let's see how this works. I think giving people choice makes sense--the default is still to pin to head, but I know that will annoy some people, particularly on big projects.