is there a way to not have bottle demand certain naming schemes for github releases

[leipzig]

i'm getting some pushback having us name our release mytool.arm64_big_sur.bottle.tar.gz instead of mytool.arm64_big_sur.tar.gz for instance. Does LiveCheck address this?

[gromgit]

Does LiveCheck address this?

LiveCheck answers the question "is there a new release version of the upstream sources?", so no.

As to your primary concern, the bottle filename component isn't just for show. It's a hint that the binaries in the tarball will likely require some "adjusting" on install, primarily fixing up internal Homebrew prefix-related paths:

$ tar xf ~/Library/Caches/Homebrew/mint-lang--0.16.1.arm64_monterey.bottle.tar.gz
$ otool -L mint-lang/0.16.1/bin/mint 
mint-lang/0.16.1/bin/mint:
	@@HOMEBREW_PREFIX@@/opt/libxml2/lib/libxml2.2.dylib (compatibility version 12.0.0, current version 12.14.0)
	@@HOMEBREW_PREFIX@@/opt/[email protected]/lib/libssl.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
	@@HOMEBREW_PREFIX@@/opt/[email protected]/lib/libcrypto.1.1.dylib (compatibility version 1.1.0, current version 1.1.0)
	@@HOMEBREW_PREFIX@@/opt/zlib/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.12)
	@@HOMEBREW_PREFIX@@/opt/pcre/lib/libpcre.1.dylib (compatibility version 4.0.0, current version 4.13.0)
	@@HOMEBREW_PREFIX@@/opt/bdw-gc/lib/libgc.1.dylib (compatibility version 6.0.0, current version 6.4.0)
	@@HOMEBREW_PREFIX@@/opt/libevent/lib/libevent-2.1.7.dylib (compatibility version 8.0.0, current version 8.1.0)
	/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1311.100.3)
$ mint-lang/0.16.1/bin/mint
dyld[98574]: Library not loaded: '@@HOMEBREW_PREFIX@@/opt/[email protected]/lib/libssl.1.1.dylib'
  Referenced from: '/Users/aho/tmp/mint-lang/0.16.1/bin/mint'
  Reason: tried: '/usr/local/lib/libssl.1.1.dylib' (no such file), '/usr/lib/libssl.1.1.dylib' (no such file)
Abort trap: 6

brew quietly does the necessary rewriting at bottle install time. Without that bottle in the name, anyone might be forgiven for assuming it was a "ready-to-use" binary tarball, then wonder why they're getting all sorts of weird errors like the above after manual unpacking.

[SMillerDev]

Homebrew has no requirement how you name your release. It only has requirements for its own internals.

If this will be a binary anyone can install, you can define whatever name you want it in the cask.
If this is a release of open source software homebrew will determine the bottle names so there's not much to push back on if you want it to work.

[leipzig]

ideally the root_url in the bottle block would be parameterized so you could put your artifacts in non-canonical places, or with your own scheme (as long as you used all the tags)
root_url "https://github.com/org/repo/releases/download/{version}/{class}_{version}_{platform}.tar.gz"

[carlocab]

Alternatively, you could use GitHub Packages (i.e. ghcr.io) instead of GitHub Releases so no one has to see your bottle artefacts.