Skip to content

[DRAFT] Implementation of runtime checks for deprecated elements with v2 #3674

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
wants to merge 2 commits into
base: latest
Choose a base branch
from

Conversation

muenzpraeger
Copy link

♻️ Current situation

With the upcoming breaking changes in v2 it's crucial to inform users that some of their used plugins may not work after performing the upgrade. The upgrade work relies on the plugin developers to update their plugins, which may - or may not - happen.

💡 Proposed solution

To support the users of homebridge runtime checks should be implemented to direct them at what/where things can break in case they would upgrade

⚙️ Release Notes

To be added if we're aligned on this as a viable solution.

➕ Additional Information

This implementation has the caveat that it purely (has to) rely on runtime invocation.

Example:

  • An accessory may have some unit format assigned via Characteristic.Units during creation - this will cause the warning to log. If it's loaded from cache the warning won't be logged as it's already defined.

Testing

To be added if we're aligned on this as a viable solution.

Reviewer Nudging

To be added if we're aligned on this as a viable solution.

@hjdhjd
Copy link
Contributor

hjdhjd commented Oct 12, 2024

Love the idea of this...would you be willing to take on a bit further evolution of it potentially. Essentially, many of the "fixes" (though certainly not all) are relatively trivial to make. Perhaps:

  • Create diffs to patch the plugin.
  • Point users to a "fixed" version of the plugin. In the case of abandoned plugins, a reference to a directory (likely in the homebridge org) referencing the corrected plugin.
  • Potentially patching-in-place? See patch-package and it's kin...

TL;DR: would be nice to self-heal/upgrade-in-place nonconforming plugins where possible. There will be instances where this can't be done, but it's a perennial 80/20 problem.

One of the assets Homebridge has is it's vast library of plugins...we'd love to find a way to bring them into the future without being overly encumbered by legacy code where we can be.

Welcome perspectives...

@muenzpraeger muenzpraeger marked this pull request as ready for review November 8, 2024 08:04
@donavanbecker donavanbecker marked this pull request as draft February 10, 2025 12:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants