feat: Remove support for expired Dart and Flutter versions #1052
Conversation
|
🚀 Thanks for opening this pull request! |
📝 WalkthroughWalkthroughAdds versioning and dependency management docs, Dependabot and a monthly dependency-audit workflow, CI matrix upgrades to newer Dart/Flutter SDKs, README compatibility updates, an Issue Template for version conflicts, and a Node.js script to compute 6‑month end‑of‑support dates for Dart and Flutter releases. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes
Pre-merge checks and finishing touches❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
📜 Recent review detailsConfiguration used: CodeRabbit UI Review profile: CHILL Plan: Pro 📒 Files selected for processing (3)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
🔇 Additional comments (6)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1052 +/- ##
==========================================
- Coverage 43.55% 43.50% -0.06%
==========================================
Files 61 61
Lines 3577 3577
==========================================
- Hits 1558 1556 -2
- Misses 2019 2021 +2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/dart/README.md (1)
40-45: Critical: End of Support dates don't match the 6-month policy.The EOL dates in the compatibility table don't align with the stated 6-month support window. Based on the release dates in
scripts/check-version-support.js:
- Dart 3.2 (released 2023-11-15): Next version 3.3 released 2024-02-15 → EOL should be Aug 2024, not Jan 2025
- Dart 3.3 (released 2024-02-15): Next version 3.4 released 2024-05-15 → EOL should be Nov 2024, not Apr 2025
- Dart 3.4 (released 2024-05-15): Next version 3.5 released 2024-08-15 → EOL should be Feb 2025, not Jun 2025
- Dart 3.5 (released 2024-08-15): No next version yet → EOL is N/A or TBD
Run the check-version-support.js script to generate the correct table:
#!/bin/bash # Generate correct EOL dates using the version support script node scripts/check-version-support.jsThe script output includes markdown tables that can be copied directly into the README.
🧹 Nitpick comments (12)
.github/dependabot.yml (1)
11-12: Consider using "chore" prefix for dependency updates.Using "feat" as the commit prefix for dependency updates may trigger feature releases when the updates don't add new features. Consider using "chore" or "build" instead, unless your semantic-release configuration specifically requires "feat" for patch releases.
Apply this diff if you want to use "chore" prefix:
commit-message: - prefix: "feat" + prefix: "chore"Also applies to: 22-23
.github/workflows/dependency-audit.yml (1)
30-36: Avoid duplicate command execution in audit steps.The outdated dependency checks run the same command twice (once to console, once to summary), which is inefficient.
Use
teeto output to both destinations in a single command:- name: Check for outdated dependencies id: outdated working-directory: packages/dart run: | echo "## Dart Package - Outdated Dependencies" >> $GITHUB_STEP_SUMMARY - dart pub outdated --mode=outdated || true - dart pub outdated --mode=outdated >> $GITHUB_STEP_SUMMARY || true + dart pub outdated --mode=outdated | tee -a $GITHUB_STEP_SUMMARY || trueAlso applies to: 62-68
scripts/check-version-support.js (1)
18-31: Add validation comments for manual release date updates.The hardcoded release dates require manual updates. Consider adding a comment with the source URL for these dates to help maintainers keep them current.
// Dart version releases (update this manually as new versions are released) +// Source: https://dart.dev/get-dart/archive const DART_RELEASES = [ { version: '3.2', latest: '3.2.6', releaseDate: '2023-11-15' }, { version: '3.3', latest: '3.3.4', releaseDate: '2024-02-15' }, { version: '3.4', latest: '3.4.4', releaseDate: '2024-05-15' }, { version: '3.5', latest: '3.5.3', releaseDate: '2024-08-15' }, ]; // Flutter version releases (update this manually as new versions are released) +// Source: https://docs.flutter.dev/release/archive const FLUTTER_RELEASES = [ { version: '3.16', latest: '3.16.9', releaseDate: '2023-11-15' }, { version: '3.19', latest: '3.19.6', releaseDate: '2024-02-15' }, { version: '3.22', latest: '3.22.3', releaseDate: '2024-05-15' }, { version: '3.24', latest: '3.24.3', releaseDate: '2024-08-15' }, ];.github/ISSUE_TEMPLATE/---3-version-conflict.md (1)
40-43: Add language identifier to error message code block.The code block for the error message should specify a language for proper syntax highlighting and to satisfy markdown linting rules.
**Error Message:** -``` +```text Paste the full error message from `dart pub get` or `flutter pub get`</blockquote></details> <details> <summary>VERSIONING_POLICY.md (1)</summary><blockquote> `36-43`: **Clarify "API impact" criteria in version bump table.** The distinction between "breaking API impact," "non-breaking API impact," and "without API impact" for major dependency changes may be unclear to contributors. Consider adding examples or a footnote explaining what constitutes each category. Add a footnote or examples section: ```diff | Major with breaking API impact | Major | | Major with non-breaking API impact | Minor | | Major without API impact | Patch | | Minor | Patch | | Patch | Patch | + +**Examples:** +- Breaking API impact: Dependency changes a method signature we expose in our public API +- Non-breaking API impact: Dependency adds new features we expose +- Without API impact: Dependency is internal-only or changes don't affect our public APIMIGRATION_GUIDES.md (7)
21-25: Add language specifier to code block.Code blocks should specify their language for syntax highlighting. This error output block should use a language identifier.
-``` +```plaintext Because your_app depends on parse_server_sdk ^8.0.0 which depends on dio ^5.0.0, and your_app depends on another_package ^2.0.0 which depends on dio ^6.0.0, version solving failed. -``` +```
51-51: Wrap bare URL in markdown link syntax.Bare URLs should be wrapped in markdown links for better formatting and accessibility.
-1. Go to https://github.com/parse-community/Parse-SDK-Flutter/issues +1. Go to [Parse SDK issues](https://github.com/parse-community/Parse-SDK-Flutter/issues)
79-82: Add language specifier to code block.This error output code block should specify a language identifier for consistency with other blocks in the document.
-``` +```plaintext Because parse_server_sdk >=8.0.0 requires SDK version >=3.2.6 <4.0.0, and your project has SDK version 2.19.0, version solving failed. -``` +```
113-114: Wrap bare URLs in markdown links.For consistency and better formatting, these URLs should be wrapped in markdown link syntax rather than appearing as bare URLs.
-Dart migration: https://dart.dev/guides/language/evolution -Flutter migration: https://docs.flutter.dev/release/breaking-changes +Dart migration: [https://dart.dev/guides/language/evolution](https://dart.dev/guides/language/evolution) +Flutter migration: [https://docs.flutter.dev/release/breaking-changes](https://docs.flutter.dev/release/breaking-changes)
154-157: Add language specifier to code block.This error output block should include a language identifier for consistency.
-``` +```plaintext Because package_a depends on http ^0.13.0 and package_b depends on http ^1.0.0, and both are required by your app, version solving failed. -``` +```
188-188: Fix heading level to skip only one level.Markdown heading levels should increment by only one level at a time. Change this h4 to h3.
-#### I Need Dart 3+ Features But Parse SDK Doesn't Support Them Yet <!-- omit in toc --> +### I Need Dart 3+ Features But Parse SDK Doesn't Support Them Yet <!-- omit in toc -->
194-194: Hyphenate compound modifier."Dart 2.x compatible" should be hyphenated as "Dart 2.x-compatible" when used as a compound modifier before "patterns".
-4. Temporarily use Dart 2.x compatible patterns +4. Temporarily use Dart 2.x-compatible patterns
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (10)
.github/ISSUE_TEMPLATE/---3-version-conflict.md(1 hunks).github/dependabot.yml(1 hunks).github/workflows/ci.yml(6 hunks).github/workflows/dependency-audit.yml(1 hunks)CONTRIBUTING.md(1 hunks)MIGRATION_GUIDES.md(1 hunks)VERSIONING_POLICY.md(1 hunks)packages/dart/README.md(3 hunks)packages/flutter/README.md(3 hunks)scripts/check-version-support.js(1 hunks)
🧰 Additional context used
🪛 LanguageTool
MIGRATION_GUIDES.md
[grammar] ~194-~194: Use a hyphen to join words.
Context: ...ate yourself 4. Temporarily use Dart 2.x compatible patterns ### CI/CD Pipeline ...
(QB_NEW_EN_HYPHEN)
VERSIONING_POLICY.md
[style] ~10-~10: Some style guides suggest that commas should set off the year in a month-day-year date.
Context: ...:** - Dart 3.3.0 released: February 15, 2024 - Dart 3.2.x end-of-support: August 15,...
(MISSING_COMMA_AFTER_YEAR)
packages/dart/README.md
[style] ~35-~35: Using many exclamation marks might seem excessive (in this case: 4 exclamation marks for a text that’s 2788 characters long)
Context: ...ificant version (major or minor).
[!Note]
Support windows are calculated ...
(EN_EXCESSIVE_EXCLAMATION)
[style] ~36-~36: ‘advance notice’ might be wordy. Consider a shorter alternative.
Context: ...he next Parse SDK major release without advance notice. For full details, see [VERSIONING_POLI...
(EN_WORDINESS_PREMIUM_ADVANCE_NOTICE)
packages/flutter/README.md
[style] ~38-~38: Using many exclamation marks might seem excessive (in this case: 5 exclamation marks for a text that’s 3110 characters long)
Context: ...heck both SDK compatibility tables. > [!Note] > Support windows are calculated f...
(EN_EXCESSIVE_EXCLAMATION)
[style] ~39-~39: ‘advance notice’ might be wordy. Consider a shorter alternative.
Context: ...he next Parse SDK major release without advance notice. For full details, see [VERSIONING_POLI...
(EN_WORDINESS_PREMIUM_ADVANCE_NOTICE)
🪛 markdownlint-cli2 (0.18.1)
.github/ISSUE_TEMPLATE/---3-version-conflict.md
41-41: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
MIGRATION_GUIDES.md
21-21: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
51-51: Bare URL used
(MD034, no-bare-urls)
74-74: Link fragments should be valid
(MD051, link-fragments)
79-79: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
113-113: Bare URL used
(MD034, no-bare-urls)
114-114: Bare URL used
(MD034, no-bare-urls)
154-154: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
188-188: Heading levels should only increment by one level at a time
Expected: h3; Actual: h4
(MD001, heading-increment)
packages/flutter/README.md
37-37: Blank line inside blockquote
(MD028, no-blanks-blockquote)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (7)
- GitHub Check: Test Dart 3.2
- GitHub Check: Test Dart 3.3
- GitHub Check: Test Dart 3.5, macOS
- GitHub Check: Test Dart 3.5, Windows
- GitHub Check: Test Flutter 3.24, Windows
- GitHub Check: Test Flutter beta
- GitHub Check: Test Flutter 3.24, macOS
🔇 Additional comments (14)
.github/workflows/ci.yml (1)
17-19: LGTM! Clear documentation of version support policy.The added comments effectively document the 6-month support window policy and reference the comprehensive VERSIONING_POLICY.md. This helps maintainers understand when to remove older versions from the CI matrix.
Also applies to: 32-32, 42-42, 87-89, 102-102, 112-112
scripts/check-version-support.js (3)
38-42: LGTM! EOL calculation logic is correct.The function correctly adds 6 months to the next release date to calculate the end-of-support date, which aligns with the stated policy.
252-254: Module exports are well-structured.The script properly exports key functions for programmatic use while supporting CLI execution, following Node.js best practices.
49-51: Based on my verification through official sources, I've found important discrepancies in the review comment's verification request. Let me provide the rewritten review comment:
Verify timezone-aware date handling and correct release date references.
The
formatDatefunction usestoISOString()which converts to UTC. If the input dates are intended to be in a specific timezone, this could cause off-by-one-day errors. However, the release dates cited in the verification request contain inaccuracies:
- Dart 3.2: November 15, 2023 ✓
- Dart 3.3: February 15, 2024 ✓
- Dart 3.4: May 14, 2024 (not May 15)
- Dart 3.5: August 6, 2024 (not August 15)
Verify that the actual release dates in the
DART_RELEASESandFLUTTER_RELEASESarrays match official sources:If the script contains incorrect dates, they should be corrected. Additionally, consider whether the UTC conversion in
formatDatealigns with the intended timezone semantics.CONTRIBUTING.md (1)
13-26: LGTM! Clear contribution guidance added.The new sections effectively guide contributors on commit message format, dependency management, and framework support policy. The cross-reference to VERSIONING_POLICY.md ensures contributors can find detailed information when needed.
.github/ISSUE_TEMPLATE/---3-version-conflict.md (1)
1-77: LGTM! Comprehensive issue template.The template provides a well-structured format for users to report version conflicts, with all necessary information fields and helpful references to migration guides. This will make it easier to triage and resolve dependency issues.
VERSIONING_POLICY.md (1)
1-68: LGTM! Comprehensive and clear versioning policy.The document effectively addresses the issue #968 by establishing a 6-month support window based on the next significant version release date, rather than the previous "1 year after release" policy. The policy is well-structured, includes practical examples, and provides clear guidance for maintainers.
packages/dart/README.md (2)
33-36: LGTM! Policy clearly states the new 6-month support window.The updated compatibility section correctly reflects the PR objective: changing from "1 year after release" to "6 months after the next significant version release." The note about support windows and the reference to VERSIONING_POLICY.md provide helpful context.
47-57: Helpful troubleshooting guidance for version conflicts.The numbered checklist and reference to the Version Conflict Guide provide a clear path for users encountering dependency issues. This aligns well with the new issue template and policy documentation.
packages/flutter/README.md (3)
33-33: Verify policy window aligns with VERSIONING_POLICY.md.The README states a 6-month support window, but the PR objectives reference a 12-month upgrade window based on the next significant Dart/Flutter release. Confirm that the 6-month window is intentional for Flutter specifically (with 12 months potentially applying to Dart), or if this should be harmonized. This should be consistent with the referenced VERSIONING_POLICY.md.
43-48: Verify end-of-support dates are correctly calculated.Ensure that each end-of-support date is accurately calculated as 6 months from the release date of the next higher Flutter version (not from the version's own release date). Provide verification that these dates align with official Flutter release dates.
50-60: Clear, actionable conflict resolution guidance.The Handling Version Conflicts section provides a practical step-by-step approach with proper cross-references to MIGRATION_GUIDES.md and related documentation. Well structured for developer self-service.
MIGRATION_GUIDES.md (2)
196-220: Well-structured CI/CD troubleshooting guidance.Clear step-by-step instructions with appropriate code examples and proper language specifiers. Covers version verification, cache management, and dependency repair.
221-247: Comprehensive coverage of platform-specific and device support scenarios.Good practical guidance on Flutter Web conflicts and device support considerations, with clear resource links and policy references. The additional resources section properly directs readers to versioning policy and related documentation.
mtrezza
changed the title
|
BREAKING CHANGE: Drops support for Dart/Flutter versions that have exceeded their 6-month support window after the next significant version release, specifically Dart 3.3, 3.4, 3.5, Flutter 3.19, 3.22, 3.24. |
mtrezza
changed the title
1 participant
Closes #968
Summary by CodeRabbit
Documentation
Chores
Other
✏️ Tip: You can customize this high-level summary in your review settings.