macOS homebrew package (was: Re: Survex 1.2.36 released)

[Robert Jones]

Ah great, you're one step ahead of me already. I tend to agree that the
private tap is more suited given the infrequent nature of updates/niche
audience.

Yes, if the formula is in the core homebrew repository, then any changes
require a PR.

The one thing you do get 'for free' is their CI/hosting of binary bottles,
but this can be applied to taps also.

I haven't played much with building binary bottles, and they're by no means
necessary but I did find some helpful notes on generating these with Travis
CI in the same manner as the core homebrew team:

https://gist.github.com/maelvalais/068af21911c7debc4655cdaa41bbf092

Rob

On Fri, 20 Jul 2018 at 16:14, Olly Betts <olly at survex.com> wrote:

> On Fri, Jul 20, 2018 at 03:49:04PM +1000, Robert Jones wrote:
> > Thanks for posting that. I'm just testing that it builds on OSX 10.14 at
> > the moment. It's taking a while as homebrew needs to build all
> dependencies
> > from source. I'll let you know the outcome.
>
> I already did some testing via travis-ci and it builds OK with:
>
> osx_image: xcode9.4     Xcode 9.4.1     OS X 10.13
> osx_image: xcode8.3     Xcode 8.3.3     OS X 10.12      (current default)
> osx_image: xcode7.3     Xcode 7.3.1     OS X 10.11
>
> But not with:
>
> osx_image: xcode6.4     Xcode 6.4       OS X 10.10
>
> > The only downside of the current 'install from URL' approach is that
> > there's no version control - homebrew won't check for updates to the
> > formula.
> >
> > I suggest for consistency you create a separate git repository on github
> to
> > track releases that can be tapped as such:
>
> Yeah, the URL was really just a temporary solution until I had a chance
> to discuss with you whether you wanted to try submitting it to homebrew
> again, or if we wanted to maintain a private "tap".
>
> If it's submitted to (and accepted by) homebrew, does that mean each
> new version needs a PR opening with them?  If so, a private tap would
> actually get new versions to users faster so perhaps that's the better
> approach anyway.
>
> I'm happy to set up a repo if that's the route we go - it seems the
> formula isn't likely to need to change often, and updating for a new
> release should usually be just a matter of updating the version and
> checksums, which can be automated as part of the script I already use
> to build a new release.
>
> Cheers,
>     Olly
>