Introduce latest versioned formulae

[quackerex]

Verification

• This issue's title and/or description do not reference a single formula e.g. brew install wget. If they do, open an issue at https://github.com/Homebrew/homebrew-core/issues/new/choose instead.

Provide a detailed description of the proposed feature

For versioned formulae seperate it from its non versioned formula.

For example currently ruby@3.4 is aliased with ruby.
If I do brew install ruby@3.4, it's install ruby. So when ruby 3.5 is released Homebrew will upgrade it.
However we can make brew install ruby@3.4 install ruby@3.4. So when ruby 3.5 is released it is still pinned to ruby 3.4.x releases.

What is the motivation for the feature?

The idea is to match formula dependencies behaviour to formulae installation.

For example if I add ruby@3.4 as a dependency the formula stays pointed to @3.4 and not ruby

How will the feature be relevant to at least 90% of Homebrew users?

Less confusion with versioned formulae. As there is no difference between installing latest versioned formulae and old versioned formulae.

What alternatives to the feature have been considered?

Accept the current behaviour :(

[MikeMcQuaid]

@Homebrew/maintainers @Homebrew/core I think this is a pretty good argument for saying we should basically keep versioned formulae as the primary names and make e.g. the ruby alias point to ruby@3.4 (rather than the opposite) for all versioned formulae like this.

Thoughts?

[samford]

Years back, I was contributing some changes to a third-party tap and ended up going down a similar rabbit hole with aliases and versioned formulae (assuming I'm understanding this situation correctly). I suggested that the maintainers use versioned formulae and create an unversioned alias that points to the newest version (keeping it up to date as later versioned formulae are added). That setup allows users to install a specific major/minor version (and stay on that version without worrying about being upgraded to a new major/minor) while also providing the unversioned alias for users who always want the newest version (and to be automatically upgraded to newer major/minor versions). In my view, this setup was the best solution out of the available options because it allows for both use cases.

As this issue mentions, the shortcoming of having a ruby@3.4 alias point to a ruby formula is that users install the former expecting that it will stay on 3.4.x versions but this won't be the case when ruby is updated beyond 3.4. I don't think there's a downside to having a ruby alias point to ruby@3.4 (and updating the alias to point to the next Ruby formula when the next versioned formula is created) but I may be overlooking something. I vaguely remember mentioning this issue back when we were creating the current alias setup (and suggesting this alternative approach) but I may be mistaken. Either way, I'm in favor of having an unversioned alias (e.g., ruby) pointing to the newest versioned formula in situations like this.

[Bo98]

I don't think there's a downside to having a ruby alias point to ruby@3.4

The downside is if you just want "any Ruby" then brew upgrade will break your setup every year when PATH=/opt/homebrew/opt/ruby/bin:$PATH suddenly disappears (or on Linux: it moves to keg-only).

There's definitely situations where it may be better to lift versioned formulae to be the "main" formula, but I don't think this issue is necessarily one of them as it just shifts the problem to a different set of users. I think a better approach here is to make brew remember what the user has requested so they don't need to worry about internal details like what is an alias and what is an actual formula. Ideal flow would be brew install ruby will install the latest Ruby and follow that and brew install ruby@3.4 sticks on 3.4.x, basically by storing the "requested" name and always following that rather than whatever the canonical name was at the time of install.

[samford]

Ahh, I figured there had to be something I was missing. I should clarify that I'm not married to any particular implementation and anything that addresses this issue without trading it for a different issue makes sense to me 👍

[MikeMcQuaid]

The downside is if you just want "any Ruby" then brew upgrade will break your setup every year when PATH=/opt/homebrew/opt/ruby/bin:$PATH suddenly disappears (or on Linux: it moves to keg-only).

I don't think most users are relying on the opt-link to work here. It's also something we can handle better so it points to "any installed ruby" instead.

Ideal flow would be brew install ruby will install the latest Ruby and follow that and brew install ruby@3.4 sticks on 3.4.x, basically by storing the "requested" name and always following that rather than whatever the canonical name was at the time of install.

We do do that but only if ruby@3.4 is the name of the formula/keg (hence my proposal).

[Bo98]

I don't think most users are relying on the opt-link to work here.

The post install instructions tells people to rely on the opt-link.

We do do that but only if ruby@3.4 is the name of the formula/keg (hence my proposal).

Why do we only have that behaviour for that way round? Sounds weirdly specific to store the requested name only in certain circumstances.

[MikeMcQuaid]

I don't think most users are relying on the opt-link to work here.

The post install instructions tells people to rely on the opt-link.

Yes. I still hold that I don't think most users are relying on it working the way you've noted here.

Why do we only have that behaviour for that way round? Sounds weirdly specific to store the requested name only in certain circumstances.

It can only really work that way around because of the Cellar names changing.

[Bo98]

I still hold that I don't think most users are relying on it working the way you've noted here.

Searching GitHub for /opt/homebrew/opt/ruby/bin comes up with 2000 results so I don't really agree people aren't using opt-links like I also have been.

But if there is logic already as you say to handle this for versioned formulae then that covers that issue anyway.

There was already another reason to give Ruby the Python-like treatment: so that the libruby dylib ID correctly points to ruby@ so that installed gems survive upgrades better.

[MikeMcQuaid]

There was already another reason to give Ruby the Python-like treatment: so that the libruby dylib ID correctly points to ruby@ so that installed gems survive upgrades better.

Yup, strongly agree with that. It may be case-by-case for formulae but in general I think the Python/newer way makes more sense than the Ruby/older way.

[SMillerDev]

This does make every update a lot more work though, since we don't point to aliases in formulae so all dependents need to be updated.

[MikeMcQuaid]

@SMillerDev Technically, kinda the opposite: you don't need to update any dependents immediately.

[SMillerDev]

But you do need to update them in the formula. Which isn't the case for a depends_on "ruby"

[MikeMcQuaid]

@SMillerDev Yup, true. It's a bit easier to split up PRs compared to e.g. revision bumps, though and feel like we've got a good feel on how to do this from Python.

[quackerex]

Thank you for considering this ❤️

we've got a good feel on how to do this from Python.

I remember brew auto upgrading python minor versions like changing python@3.13 to python@3.14 when it released. If that the case, I still think it makes more sense not to update from the listed @ version.