The point I responded to was about the new gauge card. It was mentioned in the blog post of this release, so it was covered properly, but the OP was asking why it’s not in the full release notes, to which I pointed out that it is only for the core and that the frontend has its own full release notes. Of course, the core needs to support certain frontend changes, but I don’t think the full core release notes is the primary place to expect to see frontend changes. I honestly don’t see the issue and I don’t think there’s reason to make this suspect.
It’s not “Suspect” , not sure why you came to that conclusion , it’s more “neglective”
to assuming people wouldn’t care that their front-end changes with a CORE Release 
… And therefore , there should be a HighLighted Url, In the CORE release to the Front-End Release
Honestly, I see the issue—and it’s a big one.
The frontend is released together with the core, without a separate release cycle. From a user’s perspective, there is only a single release cycle.
Theming is officially supported, so any frontend changes that affect it should be documented in the release notes. Moreover, even frontend changes unrelated to theming should be communicated to users—for the same reasons the core team documents its changes.
I don’t mind whether they prefer managing separate blog posts or merging them into one. However, the lack of proper coverage of frontend changes has been a long-standing issue. In fact, a similar problem used to be with core releases. It turned out into release blog posts—something I genuinely appreciate.
2 Likes
That’s not true, it’s a separate release cycle. Many core releases come with no frontend updates, and technically the frontend is released nightly if there are changes.
For a user? I didn’t noticed my HA instance updates FE without updating the core.
A user can choose any frontend version to use through the frontend integration.
It slightly shifts the perspective.
The real question is: how many users actually use or are even aware of this distinction? I’d assume mostly developers and perhaps some alpha testers.
I’d argue that the majority of users have no awareness that the frontend has separate release cycle. From their point of view, it’s simply one update together with core.
With that in mind, I stand by my original point: frontend changes should be communicated similarily to core changes. IMO it would be helpful to sync it with core releases.
5 Likes
Sometimes i’ve seen a separate front-end update, but most times they come with a small-tiny note(line inbetween Bumps and fixes) in the core-full-change-log … although one can “assume” it’s there, when i.e a Change like i.e Gauge-Card is announced(in CORE-Release)
They are communicated. Let me show you:
From blog post:
Click link.
Click release link
See list.
As for theme variables, they are covered in the theming docs as soon as the release is live.
I know it’s available “somewhere”. Obviously, it’s not enough, proven by every-few-months-shitstorm about unexpectedly changed vars
This is why I wrote:
communicated similarly to core changes
It’s crucial to pinpoint breaking changes and important changes in an easily readable, consistent text.
It’s my opinion about how to improve communication about changes. You don’t need to argue, I’m not going to change that.
3 Likes
Could you explain this a little more? I’m probably stupid, but I don’t understand how to do this.
2 Likes
Please create a separate thread for this, thanks.
1 Like
I don’t think anything to do with theme variables are ever mentioned in the release notes for core. They’d be in the release notes for frontend, as far as I understand. There are multiple updates to frontend in the release notes.
-
Update frontend to 20260325.0 (@bramkragten - #166497)
-
Update frontend to 20260325.1 (@bramkragten - #166614)
-
Update frontend to 20260325.4 (@bramkragten - #166970)
-
Update frontend to 20260325.5 (@bramkragten - #167050)
I was not starting an argument, debate, or trying to prove anyone right or wrong. Could they be better highlighted in the only release notes that most users read? Yes, absolutely.
Edit: clarifying my last sentences.
Perhaps yes, perhaps no… I do not care if it is mentioned/referenced elsewhere. If there are sort of breaking changes introduced, these should be at least mentioned in main post explicitly, (eventually referencing to details) not hidden in some cryptic to average user notes as update to frontend. How average user read such reference is ‘OK, that was something not working in front end and we fixed it’.
Also @Petro:
This is exactly how it is not communicated properly: Update frontend to xxxx means nothing! You need to go to another post, which people won’t do, as there are 100+ (literary, I counted this) links with references to some places with specific information.
BTW, what you are showing here is not mentioned in main thread either. You need to go to list of all changes (another link) and there you can find (again meaningless explanation of nature of change):
- Update frontend to 20260325.5 (@bramkragten - #167050)
- Update frontend to 20260325.1 (@bramkragten - #166614)
- Update frontend to 20260325.4 (@bramkragten - #166970)
These are just another links referencing to yet another places in GitHub where you can find details (really, see screenshot below). How can you imagine average user finding information about specific change if it is buried so deep across different, Especially that these explanations explain nothing:
What would be wrong in stating instead:
- Update frontend to 20260325.0, which introduces new theme variable, make sure you update your custom theme to use these.
3 Likes
Like the PR says: It’s a dependency update. This means it incorporates all changes from another release. Surely it cannot be expected to reiterate a whole changelog in a single commit message? I’ve never seen it done differently in all my time in software development. Maybe a brief summary to highlight a major change, but nothing more.
The most sensible change to me would be to also link the frontend changelog to the blog post, but the current changelog would need to be brought up to the same style as the core changelog. That said, even the core changelog can be made clearer. I do have empathy for the massive amount of changes the dev team needs to deal with. In the end, I’ve always found the changes, one way or another.
I won’t participate in this thread after this message.
Debating what does and does not count as being included in release notes is pointless since it can be bent however you want. One could argue that the blog post isn’t the actual release notes, but the summary of the release notes that no one seems to want to read themselves and then get annoyed when changes that are relevant to them are not included in the summary. Asking someone else to do the work you are not willing to do yourself is hypocritical. I knew the frontend changes were in the release notes because I read the all changes section each release. If there is mention of something relevant or interesting to me, then I click through to see what it is.
I also read the summary since that has the big changes, but changes in variables is going to be a pretty small, if not noisy, subset of users.
I have also missed mention of changes in the release notes.
I have also made suggestions on what to present in the summary.
If I really wanted to effect change, then I’d get more involved with the betas and I would read PRs and FRs more consistently and follow the roadmaps more closely. At this point, I read what I’m interested in and then make plans around that.
This is just a hobby. Hobbies should be fun.
5 Likes