The semver spec doesn't specifically address such changes, focusing more on API-level changes. The Ruby community seems to have boiled semver down to:
PATCH 0.0.x level changes for implementation level detail changes, such as small bug fixes
MINOR 0.x.0 level changes for any backwards compatible API changes, such as new functionality/features
MAJOR x.0.0 level changes for backwards incompatible API changes, such as changes that will break existing users code if they update
Based on the above, it's somewhere between a patch and a major release, which doesn't help. In practice, Rails tends to issue a patch release that emits warnings when on an unsupported configuration, waits until the breaking release is ready, then releases a new major or minor release based on how much public API has changed.

That all said, I suspect Ruby 1.8 use today is only on legacy systems that originally shipped with Ruby 1.8 and have never been manually updated using RVM or rbenv. Basically 2012-era systems never since upgraded.

Rails 4 was the first to drop support for 1.8.7, being 1.9 and above. And that hasn't hindered its usage: https://infinum.co/the-capsized-eight/articles/analyzing-rubygems-stats-v2015

So I'd personally go for a minor release with performance improvements if you issue a warnings release first. If accompanied by API changes or for strict interpretation of semver, a major release is called for.


Louis.

Sent from my iPhone

> On Feb 28, 2016, at 2:50 PM, Bill Dueber <[log in to unmask]> wrote:
> 
> Ruby 1.8 was EOL'd about 2.5 years ago, so in theory everyone should be
> long off of it. In practice, well, I thought I'd ask before making any
> releases that change that.
> 
> Sidenote: does dropping supported for a long-EOLd version of the software
> constitute a major version change under SemVer? None of the public
> interfaces would change (it's a performance-focused release I'm
> considering).
> 
> -- 
> Bill Dueber
> Library Systems Programmer
> University of Michigan Library