Closed davidn closed 2 weeks ago
The release notes are copied from upstream for example:
Features
bump [@zwave-js/server](https://redirect.github.com/zwave-js/server)[@1](https://redirect.github.com/1).39.0 ([#3970](https://redirect.github.com/zwave-js/zwave-js-ui/issues/3970)) ([ab24962](https://redirect.github.com/zwave-js/zwave-js-ui/commit/ab2496231ff3e8403d5b06e5f92df24b908781d6))
bump zwave-js@13.10.2 ([#3965](https://redirect.github.com/zwave-js/zwave-js-ui/issues/3965)) ([f909f84](https://redirect.github.com/zwave-js/zwave-js-ui/commit/f909f84185cdad7bcf6e8b7d37c65da1b781cad2))
bump zwave-js@13.10.3 ([#3968](https://redirect.github.com/zwave-js/zwave-js-ui/issues/3968)) ([885ea26](https://redirect.github.com/zwave-js/zwave-js-ui/commit/885ea266644412af3c81b859543f00c5148147bf))
As the upstream doesn't publish the fixes, what would you suggest be done here?
This add-on updates dependencies; I'm sorry, but I'm not planning on copying all upstream releases notes. It is also odd to do, as in, Unbuntu wouldn't merge all upstream release notes for all packages they update?
The dependency bumps are linked and contain all details you'd need.
Nevertheless, thanks for the suggestion though 👍
../Frenck
It could be better though… the links are not actually helping here as it is links to yet more bumping of versions in PRs that don’t actually land on the release notes of the repositories.
I personally have been caught out multiple times where the underlying zwave library has broken my set up. To then check to see what changes/fixes is incredibly manual and not well linked to what is an arbitrary number in home assistant update to the actual underlying changes in the core zwave functions.
This extension is providing what is a core service to those using it, 75% of my home is zwave and I need the UI aspects that this extension provides, but even just trying to determine the included changes is painful.
I hear you, however, as said above as well; I have no plans or intention of changing it.
Sorry 🙏
../Frenck
Which is fine. Are you open to someone else potentially automating this?
Are you open to someone else potentially automating this?
I'm fine with what I have here now. As said, I don't agree on including upstream release notes from all dependencies used.
../Frenck
Problem/Motivation
The current release process generates uninformative release notes. Unless you jump through a lot of hoops, a user cannot see whether an upgrade will fix issues, have breakages, provide new features, or essentially change nothing.
Expected behavior
When updating zwave js UI addon via home-assistant, the actual changes to functionality are surfaced to the user.
Actual behavior
When the addon is updated in home assistant UI, the only note is "Update zwave-js/zwave-js-ui to vNNNNN @ someone (#PRNUM)".
Clicking through to the PR, there is an expandable section that shows the zwave-js-ui release notes, which often just state a zwave-js bump (with no link to see zwave-js updates).
From there to chase updates you must manually go to the node-zwave-js repo, keeping track of version numbers along the way.
Steps to reproduce
Do an update of zwave-js-ui addon in Home Assistant
Proposed changes
Include Z-Wave JS UI and Z-Wave JS changes, or at least major changes, in Z-Wave JS UI Addon release notes.
I understand this is conceptually a violation of the separation of changes from different components, but from the point of view of a user doing an update this would be necessary to allow them to understand the change. I don't usually expect dependencies changes to be passed through, but given that most of the relevant changes come from these two deps it seems wise in this situation. Perhaps a header like "Changes from [X]" would help prevent confusion about which component is actually shipping the change that the user gets.