Warn when installing an unsupported or end-of-lifed Ruby

[jeremy]

$ ./bin/ruby-build 1.9.3-p551 foobar
Downloading ruby-1.9.3-p551.tar.bz2...
-> https://cache.ruby-lang.org/pub/ruby/1.9/ruby-1.9.3-p551.tar.bz2
Installing ruby-1.9.3-p551...

WARNING: ruby-1.9.3-p551 is past its end of life and is now unsupported.
It no longer receives bug fixes or critical security updates.

…

Introduces warn_eol (no bugfixes or sec updates) and warn_unsupported (sec updates only) build steps.

Fixes #742

[hsbt]

Great! I agreed to add warn and unsupported flag to old definitions.

[jeremy]

This warns after downloading and before installing. That felt good, but maybe warning before download would be better. I like that knowledge about the EOL/unsupported status is part of the package install vs. the build definition as a whole.

(Also re. https://bugs.ruby-lang.org/issues/12328)

[hsbt]

@jeremy I think so. but It's good to first step for us. Thank you!

[e2]

I personally think an "after install" is most noticeable. Many people just run a command and come back when it's finished. I'm also used to gems showing notes post-install.

However, on build systems (like Travis), people usually see what's at the top (download and install).

So it probably depends how much output there is between running the command and installation.

I'm very happy about this change! Thank you!

[jasonkarns]

Late question here, but I'm curious about intended effect...

Since ruby-build only installs exact versions, if one were to install the second most recent patch release (for instance), or really any minor/patch release of the current major release that isn't the most recent, then they'd be running on a version that could potentially have unpatched bugs/security holes.

If the intent is to warn they users are installing a ruby that may have bugs/security-holes, that would apply to every ruby that isn't the latest patch release (for a given supported major version), no?

IOW, if ruby 7.1.2 were the latest release, then ruby 7.0.0, 7.1.0, 7.1.1, etc would all technically be unsupported/eol since ruby-build users don't receive patches automatically.

I guess I don't see any significant value in warning that users are on an unmaintained release line if they are already using the not-latest release?

Anyone follow what I'm getting at? Having a hard time putting this feeling into words...

[jeremy]

I see what you're getting at, @jasonkarns, but the intent is simply to give a heads up to users who need to upgrade.

We could attempt to flag that the Ruby you're installing has a newer release on the same major version, has known/fixed bugs, has known security issues, etc, but 1. these are concerns for runtime, not install-time and 2. these are orthogonal to the maintenance status of the release line itself.

[jasonkarns]

intent is simply to give a heads up to users who need to upgrade.

But isn't this true for every ruby being installed that isn't latest?

[jeremy]

Sure. You're on a different tack that what this is meant to address.

"You're on a release line whose maintenance status you need to be aware of: your application is now entering an unsupported limbo that applying latest patches/minor release won't get you out of. You'll need to upgrade to a supported release line."

not

"You're on a specific release that is old and has bug/sec fixes available."

That could be different feature, but then again, build/install-time is likely inappropriate. See https://bugs.ruby-lang.org/issues/12328 for more on this!

[jasonkarns]

Thanks for explaining the rationale a bit! :)

On Wed, Nov 16, 2016 at 6:28 PM, Jeremy Daer notifications@github.com
wrote:

Sure. You're on a different tack that what this is meant to address.

"You're on a release line whose maintenance status you need to be
aware of: your application is now entering an unsupported limbo that
applying latest patches/minor release won't get you out of. You'll need to
upgrade to a supported release line."

not

"You're on a specific release that is old and has bug/sec fixes
available."

That could be different feature, but then again, build/install-time is
likely inappropriate. See https://bugs.ruby-lang.org/issues/12328 for
more on this!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#942 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAHUpFATgNy71qmxf4N95pBXyPRkTXq8ks5q-5GhgaJpZM4ITVwY
.

[mislav]

@jasonkarns Also, if a bunch of my projects are configured to use version 2.2.3, perhaps by .rbenv-version file, I don't want ruby-build to suddenly start telling people who rbenv install in my project's directory that they're using an "unsupported" Ruby version just because 2.2.4 came out yesterday.