@p-linnane please check previous commit history how to format your commit message correctly.

@klutchell FYI: here's one of the first external contributions to a Flowzone enabled project, which requires to be signed by our keys; I guess we need to figure out a way to build/test/package these.. Idk how to do it ATM, need to think about it a bit.

Some inspiration:
https://stackoverflow.com/a/63237162/1559300
openmainframeproject/feilong#367 (comment)
https://securitylab.github.com/research/github-actions-preventing-pwn-requests/
https://dev.to/petrsvihlik/using-environment-protection-rules-to-secure-secrets-when-building-external-forks-with-pullrequesttarget-hci

balenaetcher is no longer updated in homebrew-cask due to the maintenance demand of multiple stable releases per day.

@p-linnane I saw this message in the brew info output for Etcher, but I'm just wondering if there have been some crossed wires here. I checked #3853 which I'm guessing is what this relates to but if I'm understanding it correctly this was simply a temporary occurrence to get dependencies up to date. As @ab77 mentioned on the issue Renovate has now been disabled again so there won't be continued releases every day based on dependency updates.

I personally value having an up to date package available in Homebrew as I know @klutchell does and likely many others as well so just wondering if there's any reason we can't resume updates now?

@chrisys IMO we really need to implement/manage this ourselves, same for other package repositories.

There needs to be some careful thought given as to how this is implemented, in terms of cadence for one. Since HB, Macports, etc. are based on PR workflows, for every update, a PR needs to be open against these repositories and reviewed/merged manually. This is incompatible with automatic release cadence where versions may change multiple times per day (even with bulletproof tests).

Also, with Etcher is particular, passing unit tests and merging code does not necessarily mean a working release, since the tests don't actually test the final product (ie. no e2e tests). There is a deprecated Spectron framework test stub for only one platform (Windows?) in there, which tests for an app window appearing, but doesn't actually inspect its contents. So a blank window will pass tests. We can't ever guarantee that the releases we generate will work on all platforms. It currently requires manual testing, which we don't have a lot of (any?) bandwidth for.

There will be a feature soon in flowzone to skip finalising GH releases on every merge and defer to a manual intervention. Once that ships, we can re-enable renovate on Etcher and continue it pumping out new "untested" pre-release minor/patch versions. Then someone from the Etcher team can validate a release manually, mark it final and move the latest pointer. If the Etcher team gets bored manually testing releases, they should consider implementing e2e tests using Selenium/Webdriver framework in Electron to test a user journey through the software on all supported platforms (i.e. flash image to USB). We can provide Github actions self-hosted runners with access to real USB devices for this.

We should then be able to wire an action for that "mark latest" event to open PRs against HB, Macports, Chocolatey, etc. and try to convince their gatekeepers that we are not submitting garbage.

@chrisys If a regular release cadence is back on the table, then I am open to restoring support for it in Homebrew. That said, it appears every commit is still generating a new release (4 in the last 24 hours, including this simple readme change), so I'm hesitant to readd support for now.

@ab77 If you'd like a little bit of inspiration there is a GitHub Action I see that creates cask PR's for new releases. It was adapted from a more popular action made for formulae: https://github.com/macauley/action-homebrew-bump-cask.

The bottom line is that there is no animosity on my end. I like Etcher and use it myself. I am happy to work with you on getting support back into Homebrew when the time is right.