Looking at the release notes for 2023.4, there appears to be a major breaking change that isn’t really called out. Given that the recorder schema is changed and all the data migrated to the new schema, is it actually possible for a normal user (i.e. not a tech wizard) to revert to 2023.3 in the event of a problem?
Reverting schema changes isn’t supported. What’s broken for you? We might be able to work out a solution.
Yes, if you are happy to delete your database.
Or have a backup.
Don’t think that a backup includes a database dump, at least I don’t see any indication when “untaring” the files in a backup.
Nothing’s broken for me. I’m just thinking of the wider community of users: not all of whom are experts in this stuff.
Breaking things has always been a core philosophy of this project, but sometimes it’s done in an uncaring way (IMO). Like I said in the OP, needing to delete the database and lose some history is not a major problem for me, but for the naive user?? Would they get adequate error messages and diagnostics to guide them? Did the developers actually try to downgrade?
I just wanted to confirm that this is a breaking change, and to suggest that this be made a bit more prominent than it currently is in the release notes.
As for me, I’ll adopt my usual approach - never install a .0 release; wait for at least one round of bug fixes.
I upgraded an didn’t loose old data.
Also if they try to make things better and there are some side effects, then I am ok with that. The db optimization is always welcomed, specially in Raspberry Pi or slow equipment.
The OP makes an excellent point. There is no “downgrade” path which would preserve all the recorder data collected since the upgrade. I believe the backup does include the database, so really all that’s lost is the data collected between the backup and the downgrade. That should be a time of testing and verifying, but of course there will be problems which aren’t immediately noticeable. Not a big deal for me (I don’t really count on the Recorder data for much) but it does deserve a mention in the breaking changes.
It really helps to have a test-system on which you can test the betas. I’m always sure I can upgrade (or not), because I report all issues I have with the beta.
The database gets runtime data. Interesting from a historical point of view, but not essential. You can clear it and start from scratch.
I know it’s ephemeral data, as do you. My point is that ANY non-reversible upgrade should be signaled very clearly to users.
If HA is ever to become a mainstream product rather than a hobbyist plaything, in my view, it needs to be a lot more rigorous about breaking changes. The casual user knows nothing, and cares less. They just want something that works for their environment.
I’ve made this same observation before, but I’ve come to realize that I started with a false assumption.
HA is and will forever be a hobbyist plaything. To be honest, one reason I chose HA was because of the very active development and the volume of activity seen here on this forum.
With that comes some down side. First there’s the steep learning curve to accomplish even the most basic tasks. Then there are the constant changes, all of which assume you’ve already mastered the learning curve. Finally, there’s the fact that, like any open-source project, changes are made at the whim of the developers. A classic example is all the UI changes being made to “dumb down” the interface and make it look more trendy. Some of these provide no value to existing users, but look great on the developer’s resume.
This is what we signed up for. The alternative is to buy an off-the-shelf, propriety system and be locked into that vendor’s cloud ecosystem. Given that choice, I’ll probably stick around.