zan1456/flutter
1
0
Fork 0
forked from firka/flutter
Code Pull Requests Activity

Clarify when override: no versioning needed label should be applied (#156342)

Browse Source 
Follow-up to https://github.com/flutter/packages/pull/7796

Part of https://github.com/flutter/flutter/issues/156259
This commit is contained in:
Loïc Sharma
2024-10-07 14:09:19 -07:00
committed by GitHub
parent 504281c9e2
commit ecf3d6c39a
1 changed files with 2 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/ecosystem/contributing/README.md
View File

@@ -21,7 +21,7 @@ Any change that needs to be published in order to take effect must update the ve
This is because the packages in flutter/packages use a continuous release model rather than a set release cadence. This model gets improvements to the community faster, makes regressions easier to pinpoint, and simplifies the release process.
(The `override: no versioning needed` label can be added to skip this check, but only if the criteria above are met, or team members agree there is a compelling reason for a new exemption. Team members: please leave a comment when adding the `override` label explaining the reason for the override.)
(The `override: no versioning needed` label can be added to skip this check if it fails, but only if the criteria above are met, or team members agree there is a compelling reason for a new exemption. Team members: please leave a comment when adding the `override` label explaining the reason for the override.)
### CHANGELOG
@@ -430,4 +430,4 @@ To reduce the risk of regression, it is important to backfill unit tests to full
We do not report code coverage on the CI, since the number can actually be misleading (for example, a 100% coverage may make PR reviewers think that everything is fine, which is not necessarily true). Instead, you (and your PR reviewer) should evaluate whether the test is complete, by actually reading the test code (rather than just looking at the coverage). You may well want to use a coverage tool as part of your evaluation.
During the migration, especially when backfilling tests, it is possible to discover existing bugs. Migration PRs should just focus on migration and should not contain bug fixes. You can either (1) fix the bug in ObjC first in a separate PR, or (2) if the bug is too hard to fix, just acknowledge the bug in a comment so that someone can fix it in the future.
During the migration, especially when backfilling tests, it is possible to discover existing bugs. Migration PRs should just focus on migration and should not contain bug fixes. You can either (1) fix the bug in ObjC first in a separate PR, or (2) if the bug is too hard to fix, just acknowledge the bug in a comment so that someone can fix it in the future.