feat(plugin-loader): warn when a plugin declares a newer core requirement#397
feat(plugin-loader): warn when a plugin declares a newer core requirement#397ChuckBuilds wants to merge 1 commit into
Conversation
…ment Upstreams local work found on this device that had never been committed or pushed. Verified functionally sound (see test plan) before packaging; not authored this session. Adds PluginLoader._warn_if_incompatible(), called once per plugin load: if a plugin's manifest declares a minimum LEDMatrix core version (via manifest['min_ledmatrix_version'], manifest['requires'] ['min_ledmatrix_version'], or the newest versions[] entry's ledmatrix_min_version/ledmatrix_min) newer than the running core's own src.__version__, logs a warning naming both versions rather than letting the plugin fail confusingly later when it hits a missing feature. Purely advisory -- never raises, so a plugin that already guards optional features with try/except keeps working exactly as before. Includes an anti-spam guard: if the core's own __version__ is itself below the ecosystem floor every shipped plugin already declares (< 2.0.0), the comparison is skipped with a debug note instead of warning on nearly every plugin. This is also why src/__init__.py's __version__ is bumped from the long-stale placeholder 1.0.0 to 3.1.0 (the actual current core version) in this same commit -- without that bump the new check would always silently no-op via the anti-spam guard, since 1.0.0 is below the 2.0.0 floor. Test plan: - test/test_loader_compat_warning.py (7 tests, new): semver parsing, warns when plugin needs newer core, silent when compatible, silent when the field is absent, reads both the requires.* and versions[].* spellings, and confirms the anti-spam guard actually suppresses the stale-core case. - Full test/test_plugin_loader.py + test/test_plugin_system.py: 38 passed, 1 pre-existing failure (test_circuit_breaker, unrelated stale-mock issue already present on origin/main) confirmed via isolated worktree comparison.
|
Warning Review limit reached
Next review available in: 59 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
Up to standards ✅🟢 Issues
|
| Metric | Results |
|---|---|
| Complexity | 18 |
| Duplication | 0 |
NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.
|
Closing as a duplicate — the version-compatibility warning ( |
1 participant
Summary
Upstreams local work found sitting uncommitted on a device — never pushed
or opened as a PR. Verified functionally sound before packaging (see test
plan); not authored this session.
Adds
PluginLoader._warn_if_incompatible(), called once per plugin load:if a plugin's manifest declares a minimum LEDMatrix core version (via
manifest['min_ledmatrix_version'],manifest['requires']['min_ledmatrix_version'], or the newestversions[]entry's
ledmatrix_min_version/ledmatrix_min) newer than the runningcore's own
src.__version__, logs a warning naming both versions — ratherthan letting the plugin fail confusingly later when it hits a missing
feature. Purely advisory; never raises, so a plugin that already guards
optional features with try/except keeps working exactly as before.
Includes an anti-spam guard: if the core's own
__version__is itselfbelow the "ecosystem floor" every shipped plugin already declares
(< 2.0.0), the comparison is skipped with a debug note instead of warning
on nearly every plugin. This is also why
src/__init__.py's__version__is bumped from the long-stale placeholder
"1.0.0"to"3.1.0"(theactual current core version) in this same commit — without that bump the
new check would always silently no-op via the anti-spam guard, since
1.0.0is below the2.0.0floor.Test plan
test/test_loader_compat_warning.py(7 tests, new): semver parsing,warns when a plugin needs a newer core, silent when compatible, silent
when the field is absent, reads both the
requires.*andversions[].*spellings, and confirms the anti-spam guard actually suppresses the
stale-core case.
test/test_plugin_loader.py+test/test_plugin_system.py: 38passed, 1 pre-existing failure (
test_circuit_breaker, unrelatedstale-mock issue already present on
origin/main— confirmed via anisolated worktree comparison).
🤖 Generated with Claude Code