Conversation
crap I did a normal merge lol, oh well |
Hi Jake, hi Nate, Would it be possible to leave a route for us to release new lint lists for pre-NNBD? It seems pretty likely we're going to want to release at least one or two versions before NNBD is stable. I guess, we can do parallel releases for pre-NNBD and post, with the yaml files the same between the two and the code having the changes in this PR. The only difficult point is versioning, we name the How about we use That would make this change WDYT? Thanks! |
Note that this is only a branch right now - so its just for doing git overrides with. We can continue development on the master branch and merge those into this branch. @davidmorgan do you want to explicitly suggest different lints with and without NNBD? Or is it that you want to have a version that doesn't have such a high min sdk constraint? If we want to release separate NNBD versions I would suggest doing |
Ah, I was thinking people not using NNBD would be unable to use the new version, but of course that's not true: they have to meet the new min version constraint but they don't have to opt into NNBD. I guess I'm okay once the min version constraint is a stable version. If I understand correctly that should be ~soon, so it will likely be before I want to release a new No need for different lints for NNBD :) Thanks! |
The min sdk constraint won't be able to be a stable version for a while I don't think (experiments aren't usable in stable SDKs), but we may want to publish something before then. However, those should only be pre-release versions if they require an experiment to be enabled in order to work. I propose that we publish |
description: >- | ||
The Dart analyzer settings and best practices used internally at Google. | ||
homepage: https://github.com/dart-lang/pedantic | ||
|
||
environment: | ||
sdk: '>=2.1.1-dev.0.0 <3.0.0' | ||
sdk: '>=2.8.0-dev <3.0.0' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should change this to <2.8.0
so that only 2.8.-dev sdks can select this release, per other comments.
I would strongly prefer not to be publishing to pub from different branches. My preference would be to keep the |
I think pre-release versions are an acceptable exception to the general rule of publishing from master. |
I'm happy with any way we can figure out to do that ;) |
I am not sure what the unawaited_futures lint would do with aFuture?
type. If it triggers we may want to allowFuture<void>?
as the argument here.I went ahead and made the api nullable, at least with the current lint implementation it does trigger and I think it makes sense to.
I also added an example since I needed to do that to test the lint behavior anyways.