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