[email protected] 1.17.3 (new formula)

[codefromthecrypt]

This adds [email protected] and backfills an alias for 1.18, as that's the current version.

Notably, Envoy 1.18 changed the config format in an incompatible way with 1.17 which is supported until next year

• Have you followed the guidelines for contributing?
• Have you ensured that your commits follow the commit style guide?
• Have you checked that there aren't other open pull requests for the same formula update/change?
• Have you built your formula locally with brew install --build-from-source <formula>, where <formula> is the name of the formula you're submitting?
• Is your test running fine brew test <formula>, where <formula> is the name of the formula you're submitting?
• Does your build pass brew audit --strict <formula> (after doing brew install --build-from-source <formula>)? If this is a new formula, does it pass brew audit --new <formula>?

---

cd Aliases;ln -s ../Formula/envoy.rb '[email protected]'

[carlocab]

Why do we need this alias? The alias will need to change when Envoy is upgraded to 1.19, so anyone using brew install [email protected] will just get an error when that happens.

[codefromthecrypt]

good q. minors are usually not compatible in envoy though what isn't compatible may not effect everyone.

For example, the pending incompatibilities of 1.19 aren't as shocking as 1.18 which dropped a config format

Knowing this, I'll leave it up to your judgement as I agree alias maintenance is added!

[carlocab]

It's not really a question of alias maintenance. I just don't see how this alias will be useful. Or do you think brew install [email protected] returning an error when Envoy is upgraded to 1.19 would be useful?

[codefromthecrypt]

TL;DR; I think most won't need this alias, and only some developers would want to pin to a minor. The problem is there is no packaging for OS/x except homebrew at the moment.

A developer of wasm (filter plugins) may want to know the version is what they think it is and won't care much about the patch version (though sometimes they also break). This has to do with the features changing fast in envoy and that there are a few non-EOL versions https://github.com/envoyproxy/envoy/blob/main/RELEASES.md#release-schedule

I see what you are saying that basically no one can rely on [email protected] for very long so possibly it is not worth doing.. that they should either not use homebrew to get a known minor, or go straight to the ghcr.io registry?

If there's a way to retain the existing last [email protected] without copy/pasting the formula, that would be best, but I don't know that option and only know the alias thing or copy/paste. If there's another way all 👂 s

[carlocab]

When Envoy 1.19 is released, will Envoy 1.18 continue to receive updates? If it will, and it also meets the rest of the criteria at https://docs.brew.sh/Versions#acceptable-versioned-formulae, then it may be possible to add an [email protected] formula when 1.19 is released.

[codefromthecrypt]

early July 1.19 will be available and a few others including 1.18 will be non-EOL, which means patch releases. So probably the worst case is for a week there could be 4 non-EOL versions out there, but since we are starting with 1.18 and usually one ages out, typically it would be 3 current non-EOL versions and of course, here we could decide to do less.

[codefromthecrypt]

probably the bigger point on https://docs.brew.sh/Versions#acceptable-versioned-formulae is "large number of people" frankly I don't think that's the case now, especially vs something like ruby.

I suppose some stats could show that's the case or not, but I'm guessing this might be a reason to close this until it becomes more popular...

[carlocab]

A "large number of people" isn't that demanding a requirement. At the moment it amounts to ~800 installs a year. If it seems likely to cross that, then we could probably have an [email protected] formula. All the earlier versions probably won't qualify, though.

That said, it's still not clear adding this alias now is still useful. Even if we merge this, and I do brew install [email protected] now, I will still get Envoy 1.19 when I do brew upgrade (when Envoy 1.19 is merged here).

[codefromthecrypt]

I think the primary use case for brew install [email protected] is CI matrix or ad-hoc switching back to the prior version because something busted or you were supporting something and there was some doubt about the version being implicated.

[carlocab]

Yes. And that'll be possible if/when there is an [email protected] formula. I don't think it's a good idea to have users relying on its existence until the PR that adds one is accepted.

[codefromthecrypt]

gotcha. so basically this is the wrong solution to the problem. Do you prefer a different PR to change the implementation or keep this one? I can see value in the comments here so inclined to change the commits instead of open+ref, but up to you

[SMillerDev]

You can just update this one

[codefromthecrypt]

OK I updated this to backfill only one previous version 1.17. This is important because its config version is still supported until next year. Hope this is ok, but please tell me if there are any issues with it*

• I noticed many formulas alias [email protected] -> ../Formula/x.rb until x.rb becomes a historical version. It seems sensible to do this also here as it will follow as a versioned formula when 1.19 is out anyway.

[carlocab]

Please squash your commits together and use the commit message [email protected] 1.17.3 (new formula)

[codefromthecrypt]

thanks so much for your help @carlocab I will try to pay back by maintaining this

[codefromthecrypt]

fyi envoy doesn't work with macOS+arm64 yet due to things including envoyproxy/envoy#16083 (comment)

[carlocab]

LGTM. Thanks, @codefromthecrypt. Away from my computer at the moment, so can't trigger a merge. Ping me later this evening (GMT) if I forget.

[codefromthecrypt]

cool looking forward to it!

[BrewTestBot]

@carlocab has triggered a merge.