Ruby question: solution for dependency version specs?

[Fred Wright]

On Sun, 17 Mar 2024, Sergio Had wrote:

> I have no idea what is going on with archaic versions, but Ruby 3.1+ 
> through ruby-devel (3.4) should work on every system.

Please stop posting falsehoods. Ruby 3.1-3.3 most certainly do *not* work 
on every system (yet), and I posted a list of the failing cases in another 
thread where you were a participant.  I haven't looked at 3.4.

> They are, and everything relevant is rb33-* etc. Unversioned one which 
> use rb18 should re updated or removed: we have no reason to keep Ruby 
> versions prior to 3.0, since 3.0 works on Tiger, and 3.1+ work on 
> Leopard through Sonoma. That also includes PowerPC systems.

Again, false.

For at least the past few years, no version of Ruby has worked on all 
systems until I personally fixed it, and I haven't had a chance to fix 
anything later than 3.0 yet.  And contrary to popular belief, Ruby 3.0 
isn't (quite) EOL yet.

As far as having multiple versions goes, Ruby is just like many other 
things, where having multiple versions is useful for (at least):

1) Testing code against multiple versions.

2) Using a textbook that is based on a particular version.

3) Avoiding brokenness in one or more versions.

No too long ago, the instructions for building the RaspberryPi docs stated 
that asciidoctor needed to be run with Ruby 2.7 because it didn't work 
properly with 3.0 (at least for their files).  While that no longer seems 
to be the case, it does serve to illustrate that newer isn't always 
better, and that it's best to give users a choice as to what version to 
use, rather than inflicting someone else's notion of the one true best 
version on them.

On Sat, 16 Mar 2024, Austin Ziegler wrote:

> I also think that the `ruby` port needs to be renamed to `ruby18` and `port
> install ruby` should *either* fail (like `port install python` or `port
> install python3` does) or it should install the latest stable version
> (updated on Christmas Day every year).

Agreed.  Presumably this came about because having multiple versions 
wasn't initially anticipated.  It's unfortunate that (unlike some other 
packaging systems) MacPorts doesn't have a way to directly make multiple 
versions of something available without resorting to the kludge of 
building the version number into the name.

Fred Wright