Add the possibility to install a previous release of an addon

Feature Requests
1

There is some case where it is necessary to install a previous release of an addon.
For example, there is a bug on the zigbee2mqtt Addon which is still in investigation, is very annoying for the zigbee network (https://github.com/Koenkk/zigbee2mqtt/issues/19747#issuecomment-1878100409).

The only workaround is to install a previous release while waiting for the fix.

For instance, HCAS does that very well, and I think it could be a very interesting feature for people who install HA with HAOS.

2

This exists already, you restore a backup containing the version (and the data structure) for the version you want.

3

Yes, that is an option for most users but consider the following:

  • new home assistant users that start from scratch may find themselves in a situation where an issue does not exist in a previous version of an addon(based on research in the community forums) but are unable to install that particular version due to not having a backup
  • many users run their installation on SBCs where limited storage space is a thing so they may not be able to keep too many backups at hand and by the time they realise that an old version of an addon would fix a particular issue (until a fix is released in a new version), the old backups may already be gone.

While I am lucky enough to be able to store years worth of backups and this is not an issue to me, I do think that having a user-friendly way for HA users to install any version of any addon regardless of their backup habits would be a great quality of life improvement for many HA fans out there.

1 Like
4

Not really, as the data structure between versions can (and will change) between versions of add-ons.
This data is (in most cases) not exposed to the user, which will make it so that when you “downgrade” your data is invalid. In most cases, the application (add-on) will then wipe out the data and start over, making you lose everything it had, and even if you then “upgrade” to the version you had, that data is lost forever.

Sure, adding a “version” field could be nice, but it has implications that most will not think of or consider when suggesting adding a “simple” thing like that.

This is why the backup is preselected when you do upgrades, as backups are the way to go back.

If you really, really, really need a different version and you do not care about the data, you can use any version of any add-on by placing it in the local addon directory with the version modification you want on it.

1 Like
5

This not exists if you don’t have backup (my case) because of a fresh re-installation.
And for a certain time you don’t have the backup (it expires).

6

I agree with that and that’s why it is under the responsability of the user. If semver major release have been installed, a user should not go back with a previous major release. Like for all HACS integration and like for all software update generaly speaking.

7

I think with HAOS it is not possible to do that cause we don’t have access to the addon directory. Am I wrong ?

8

Version strategies can not be forced.

9

It is, otherwise I would not mention it.
Look at the add-on dev docs on how to do that.

1 Like
10

“cannot” means “we don’t want to” or “is not technically possible” ?

11

Can not, even if the format was forced, there are no way to detect if an author adds breaking changes in a semver patch version

12

As you bring up HACS, (as the creator of that)I can tell you that adding that possibility there was a big mistake on my part and the data issues I explained above have happened multiple times because of it.

13

My addons repo was not loaded by SMB. If I add it, I see that it is empty:

Capture d’écran 2024-01-05 à 11.32.59

Am I missing something ?

14

Nope, those are your local add-ons.
If you have not added one yet, it is supposed to be empty.

15

ok. If I install an addon with an old release it will take precedence over the “regular” addon install ?

(like it is the case for custom-components installation which takes precedence over “core integration”).

That is exactly what I needed. Thank for the tips.

I guess we can close this FR if my understanding is right.

16

It will be a completly seperate add-on

1 Like
17

This feature save my life so many times (to patch things that the integration team will not patch in core directory). That is not a mistake but a must for me.
I agree this should be done only, at last solution and if you understand what you are doing (and respecting semver at minima).

Thank you for all the explanation, I will try that this week-end.

Have a nice year @ludeeus ! (I love your work on HACS as an integration developper)

1 Like
18

Hello,

Finally I will not do what is proposed here. Installing an addon in parallel of the official one seems a bad idea in many case. If the addon have some db or some data generally speaking, I suspect it may cause corruption.

So the initial request is still valid: have the possibility to select the release of the addon to be installed.

1 Like
19

It will cause problems, which is why I specifically mentioned that.

If you really, really, really need a different version and you do not care about the data, you can use any version of any add-on by placing it in the local addon directory with the version modification you want on it.

The same applies to running version x when data is for y as mentioned in the same message Add the possibility to install a previous release of an addon - #4 by ludeeus

20

I understand but this is the price to pay for having this feature which can “save the life” of the user in some weird cases. Maybe warning the user is necessary for such a feature.