Deprecate advanced mode option in addon config

[mdegat01]

Proposed change

Advanced mode is being removed from across Home Assistant. This deprecates the config option by ignoring it and always returning False and logging any time it is seen in config.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New feature (which adds functionality to the supervisor)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes Removal of advanced mode #6589
• This PR is related to issue:
• Link to documentation pull request: Document deprecation of advanced mode in apps developers.home-assistant#2982
• Link to cli pull request:
• Link to client library pull request: Mark advanced field in addon info as deprecated home-assistant-libs/python-supervisor-client#279

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Ruff (ruff format supervisor tests)
• Tests have been added to verify that the new code works.

If API endpoints or add-on configuration are added/changed:

• Documentation added/updated for developers.home-assistant.io
• CLI updated (if necessary)
• Client library updated (if necessary)

[mdegat01]

@agners is breaking-change the right label here? It's not actually breaking yet but it will be in the future. I don't know what other label makes sense of the ones we went through the other day though 🤔

[Copilot]

Pull request overview

This PR deprecates the add-on advanced config flag as part of the broader “advanced mode” removal, ensuring the Supervisor no longer treats add-ons as “advanced” while still tolerating the legacy field and warning when it’s present.

Changes:

• Add a validation warning when an add-on config includes the deprecated advanced field.
• Make AddonModel.advanced always return False regardless of config contents.
• Add tests to confirm the warning is emitted and that the advanced flag is ignored.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
supervisor/addons/validate.py	Logs a warning when deprecated advanced is present in add-on config validation.
supervisor/addons/model.py	Forces advanced to always be False to align with removal of advanced mode.
tests/addons/test_config.py	Adds coverage for the new deprecation warning.
tests/addons/test_addon.py	Adds coverage ensuring the advanced flag has no effect on Addon.advanced.

[mdegat01]

@agners I added needs-client-library but not exactly sure what to do there. There's no functional change there because its not being removed at this time. Do you think its proper to add a commit with comments to get the deprecation in the patch nodes of the next release of aiohasupervisor separately from supervisor? Or is this PR here enough to start the deprecation clock there too?

[agners]

@agners is breaking-change the right label here? It's not actually breaking yet but it will be in the future. I don't know what other label makes sense of the ones we went through the other day though 🤔

I'd say yes, we should mark this PR already as breaking. The label is more informational, but we want to get the attention of release notes readers early.

@agners I added needs-client-library but not exactly sure what to do there. There's no functional change there because its not being removed at this time. Do you think its proper to add a commit with comments to get the deprecation in the patch nodes of the next release of aiohasupervisor separately from supervisor? Or is this PR here enough to start the deprecation clock there too?

Hm, we left out other deprecated fields from the beginning, but that was different 🤔 Just an empty commit I would not do, we can also manually add a note to the release if we want to inform client library users.

The question maybe is if we could use the Python warnings feature to warn users on access or something? 🤔

[agners]

LGTM!

[agners]

Hm, we left out other deprecated fields from the beginning, but that was different 🤔 Just an empty commit I would not do, we can also manually add a note to the release if we want to inform client library users.

As discussed, it actually seems very sensible to add a Python comment to the client library model which says that the field is deprecated. With that we have a changelog entry as well.