Update release process to include updating homebrew formula

[kate-goldenring]

Spin is now installable via brew! During releases, we should update the homebrew formula to point to the latest release artifacts.

ref #641

[vdice]

Will we want to preserve formulas for previous Spin releases? eg when 1.5 comes out, we'd move the current spin.rb to spin.rb@1.4.1 and then update spin.rb with 1.5 values. Or, are we thinking just maintaining and updating the one formula? I assume with the former, users could brew install fermyon/tap/spin@1.4.1 whereas with the latter, no such version-pinning would be supported and users would always get the latest - is that correct?

In any case, this is more thinking ahead and isn't intended to block this PR. We can iterate, of course.

[kate-goldenring]

@vdice From my understanding, it is common practice to only support one Homebrew formula, namely the latest version of the project. If you want to support earlier versions ("pinned version formulas"), they become separate formula (like you mentioned) and you cannot simply brew upgrade to get the latest. For example, notice how Nomad's install instructions for macos only provide homebrew as an option for latest release; otherwise, you have to do a binary install: https://developer.hashicorp.com/nomad/docs/install.

in contrast, postgres releases each version as it's own pinned formula: https://www.postgresql.org/download/macosx/. Latest postgres is version 15; however if i install 14 and then brew upgrade, i stay on 14:

$ brew install postgresql@14
$ brew upgrade
$ brew list | grep postgresql
postgresql@14
$ brew install postgresql@15
$ brew list | grep postgresql
postgresql@14
postgresql@15

The only way to upgrade is to uninstall the old version and instal the new one (otherwise you get two installs) -- very unideal

My main concern here is that for some reason someone installs an older, pinned version and never moves up. But like you mention, we could take the hybrid approach and have latest always in spin.rb and then keep older versions as pinned. I'm happy with that. We should also have a retirement plan in that case -- aka we will only support the last X versions... but we probably arent there yet

[vdice]

@kate-goldenring thanks so much for filling out the gaps in my understanding. It's a bit more complex than I gathered at first. With this in mind, I'm totally in support of going with the one (latest) formula for now. We can revisit down the road, if we'd like. But, as you've pointed out, the overhead of managing different versions is non-trivial.

[kate-goldenring]

@vdice I don't think it would be too hard to manage (just extra .rb files) -- i just feel there may be a reason that many other projects only support latest ... maybe to encourage that upgrade story? I do feel like we will hit this question actually in a week when we release 1.5

[vdice]

One non-blocking though, otherwise LGTM!

[vdice]

Should we mention the specific mechanism envisioned for updating the formula? eg via PR or...?

[kate-goldenring]

I'm swinging to think we should just also support pinned versions to start for now, but i also didn't figure out the conflicts statement in the formula so we could run into the issue of multiple installs.

[vdice]

@kate-goldenring ah, yea that would be good to figure out. We can always backfill with pinned formulas, if/when we want. Perhaps we track this potential effort in an issue in the homebrew-tap repo?

[kate-goldenring]

@vdice issue to track on supporting other versions fermyon/homebrew-tap#7