RFC: Add-on downgrade/upgrade

[pvizeli]

trafficstars

Context

Currently it's not possible to install a older version of an add-on without snapshot/restore.

Solution 1 / Decision

We create a new container label: io.hass.config This map the config.json for this version into image specs. On add-on folder, we create a new history.json which include information about available version / arch / registry in a way they we need discover.

This allow us to show all older version and allow to downgrade an add-on or install a older version of this add-on.

Solution 2 / Decision

Use a warehouse and create tar files with including all information like the python wheel. Git will be the only store that handles 1 version aka latest. If we install a new version, we can create an tar including the data which we need to handle the version and store it locally, so all installed versions also with git is up and downgrade able without snapshot - but snapshot respect changed internal data better for downgrade.

[fti7]

Sounds great. Please also implement some stable/beta channel feature to avoid such issues like with the current deconz addon :-)

[frenck]

From experience, as I run 3 channels for the community add-ons, it makes no difference. Edge/beta channels only work if people actually use it. Which they don't unfortunately.

[pvizeli]

That is already possible and also with simple branch because the repo url support this. I had this also on the core addons from the old days and removed it because we have just not the manpower to maintain that.

[fti7]

If you want an User Adoption: Make it easier for them: Add an Additonal Toggle/Dropdown under the "Auto Update" Toggle (Each Addon seperately)

• Latest (Default) - Current Situation
• Stable (People with an Demand of more Stable (Auto) Updates - Like people with no Time or Remote HASS Installations (Parents; Friends; Company)) - Disable Autoupdate would also work; But thats usually an bad idea to run such things without Security Updates

Would be nice for all Components (HassOS, HASS, Addons) etc.

[ciotlosm]

That is already possible and also with simple branch because the repo url support this. I had this also on the core addons from the old days and removed it because we have just not the manpower to maintain that.

Any documentation around this? Would the add-ons have the same name?

Also noticed (might be wrong) that currently on a Reload for repositories, config.json is fetched new, so if the user updated it, but did not bump version, you actually can break running add-on. I hope the new solution fixes this.

Example:

• Add-on running version 1.0
• master on repository receives config.json update (schema and options) but doesn't yet update to version 2.0
• User gets a repo Reload and ends up with the new schema and options

I think version should be separate.

[adamoutler]

What would mark the recorded version? Individual actions on the main branch of git repository, or the latest version when the config version is updated? If recording the latest version only, what happens if Developer updates his config version and immediately begins working on the next version making a commit before HA has scanned the repo? This would mark a divergence from expectation as a developer can currently increment the version first and code second in the same push request without any adverse effects.

[Vitus-TL]

Hi, I need to downgrade the Z2M integration to version 1.30.1 due to a bug. Any progress or solution for this?

[frenck]

Hi, I need to downgrade the Z2M integration to version 1.30.1 due to a bug. Any progress or solution for this?

There is not (as you can see here in this issue). At this point, please restore backups that are created an add-on upgrade.

../Frenck

[Vitus-TL]

Hi,

I did not use this version on HA, only as stand-alone. I want to try the MQTT addon, but can’t use versions beyond 1.30.1 due to a bug

Op di 21 nov. 2023 om 08:21 schreef Franck Nijhof @.***>

Hi, I need to downgrade the Z2M integration to version 1.30.1 due to a bug. Any progress or solution for this?

There is not (as you can see here in this issue). At this point, please restore backups that are created an add-on upgrade.

../Frenck

— Reply to this email directly, view it on GitHub https://github.com/home-assistant/supervisor/issues/1843#issuecomment-1820364193, or unsubscribe https://github.com/notifications/unsubscribe-auth/AZ4AZ7JMT7NQBWFI2PNJDJTYFRI63AVCNFSM4PAOULXKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBSGAZTMNBRHEZQ . You are receiving this because you commented.Message ID: @.***>

[osmeest]

It is not sufficient to have Stable vs Latest as a choice of version. For example, all versions of Z2M non-edge are considered to be stable. Still, it may happen that something went bad in those stable releases and that it is discovered only later. If I want to try older versions, I need to restore a backup which will also rewind a number of changes and (maybe) also lose recorded information. All it takes is to propose a list of known versions. By default, latest is chosen. But it should be equally easy to install an older version. If the add-on has data, it might be that we lose that data because older version cannot use information left by the newer one. That can only be covered by restoring backup. Major.minor version should flag this situation. A complete solution would be to be able to restore only parts of a backup... But that's another story !