Add ability to omit Ruby minor/patch version when installing

[fulldecent]

Please make this work:

rbenv install 2

this and 2.7 should currently install 2.7.7.

[sandstrom]

My personal opinion is that it might make sense to allow emitting patch (though I don't mind how it works currently), but it rarely makes sense to omit minor.

[eggplants]

pyenv has already implemented this feature.

ref: pyenv/pyenv#2487

[jasonkarns]

Duplicate of #261 which has been considered and rejected.

Extra questions that must be answered were this to be considered:
In a scenario where 2.7.0 is already installed, and latest available is 2.7.1, what should rbenv install 2 do?

1. nothing; the requested version is already satisfied with an already-installed version. surprises users that it does not install the latest available
2. install 2.7.1; user gets latest released version, but surprises users that already have a satisfying version installed. Slightly more concerning, running the same command on the same machine on different days results in different behavior.

[fulldecent]

If it is not acceptable to have fuzzy matching to install/use the latest version, then a useful behavior can be that a fuzzy match will result in a message

"The latest available version of ruby 2 is ruby 2.1.99 you can install this with

Rbenv install 2.1.99"

Or whatever syntax is required to show the customer

[mislav]

Duplicate of #261 which has been considered and rejected.

@jasonkarns True, but I'm willing to reconsider it. Sometimes I'm lazy and I'd like for ruby-build to just install me the latest version of Ruby 3, whichever that is. Note that if this ships, fuzzy version matching would only work when installing, but not when activating a Ruby version through rbenv.

Extra questions that must be answered were this to be considered: In a scenario where 2.7.0 is already installed, and latest available is 2.7.1, what should rbenv install 2 do?

That's a good question! I'd vote for installing the latest available matching version, unless that exact version is already installed.

If it is not acceptable to have fuzzy matching to install/use the latest version, then a useful behavior can be that a fuzzy match will result in a message

@fulldecent That is also a good idea; thanks!

Let me think about this for a while.

[jasonkarns]

FWIW, I've poked at this with nodenv a bit. The issue we've run into is how tightly ruby-build couples the build definition file and the resulting built ruby. So what I had spiked out a few times was to add a generic function (to be used by the build def) to node-build that renames a built version according to its actual full version name. Then we could have a build definition just named 3 that operated similarly to the -dev builds (dynamically choose latest download, then rename to exact version after building).

We kept hitting gotchas, but nothing seemed horribly broken by the approach.

[jasonkarns]

@eggplants what does pyenv do in the scenario where a user requests a fuzzy version that is already satisfied by an installed version? (say: pyenv install 3.14 when 3.14.0 is already installed, but 3.14.5 is the latest available?)

Does it behave as pyenv install 3.14.0, since 3.14 is already satisfied? (exit with "already installed" message) Or behave as pyenv install 3.14.5, since that's the latest available? (actually install latest) Something else that is a blend of the two with custom messaging?