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ā€™eĢcran 2024-01-05 aĢ€ 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.