Don't use zip_release

[tjorim]

I noticed the 0.3.0b2 release has a faulty zip asset.
There doesn't seem to be a point in using this format anyway.
Is there anything I missed? Do you add anything in there that's not in the repo?

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
ha-samsung-soundbar	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Feb 8, 2024 11:27pm

[samuelspagl]

Sorry to hear that the b2 release was faulty. I started to use the zip archive because when I started to develop this integration, I took a look at other integrations and the majority of the ones I took a look at had this included.

I simply didn't know that leaving it out is the better way to do it. Let me check how the release is working then :)

[samuelspagl]

So I took a look at the integration_blueprint mentioned in the official HACS documentation. They also do zip releases there, but I saw that the release.yaml workflow looks different than mine.

The 0.3.0b2 release failed in the pipeline, and I uploaded the zip myself. So I know now that this doesn't work :D.

Is there any bigger advantage not using zip releases?

Currently I would go with adjusting the release.yaml workflow, and would test it out in the current dev branch. Still if not using zip releases is way better, than we can go with that.

[tjorim]

I confirmed with Ludeeus (dev of HACS) what the advantage/benefit is for using zipped releases. His answer was "Nothing really". If not using it, it's as simple as creating a release/tagging a version. For things as minimum required version HACS uses the hacs.json from the tag that is being downloaded anyway.

Edit: he just said there is still a difference when using the 'legacy' version (without having 'experimental' enabled, experimental is actually safer, more stable and will be the default at some point). When using non-experimental it also uses an old data format/source and downloads the custom_integration files individually instead of just the zip. However, this is not something the end-user will notice.

[tjorim]

I also think #12 is related to this. While probably a bug in HACS itself, it tried to download the zip for the main branch instead of the latest release (and accompanying tag). Of course a branch cannot have release assets like https://github.com/samuelspagl/ha_samsung_soundbar/releases/download/main/samsung_soundbar.zip.

[samuelspagl]

I also think #12 is related to this. While probably a bug in HACS itself, it tried to download the zip for the main branch instead of the latest release (and accompanying tag). Of course a branch cannot have release assets like https://github.com/samuelspagl/ha_samsung_soundbar/releases/download/main/samsung_soundbar.zip.

Yeah I also think that that happened.

But so first of all, thanks for speaking to Ludeeus and clarifying this! Just for my understanding, when changing this, I would just do a release, without attaching an additional .zip archive to it, and HACS is just doing all the magic. Right?

If the experimental version is safer, we can also already use that one.

[tjorim]

Yes, release makes a tag, custom_components gets pulled for that tag. Another idea Ludeeus had was because there was no official release yet (a pre-release doesn't count) at the time users added your custom repo. In that case it would also fail to find the latest release and pull it. The HACS experimental features is up to the user, nothing a publisher can do about it.

[samuelspagl]

Okay so from my point of view, we can try that out.
Could you please add a Changelog entry and bump the version? I would merge it afterwards.