On Fri, Jan 08, 2016 at 10:37:32PM +0000, Eric Wong wrote: > Aaron Patterson <[email protected]> wrote: > > The main reason I bumped it up to Ruby 2.2.x is because that will be the > > minimum version of Ruby I'll be stuck with throughout Rack 2.x's > > lifetime. IOW, I can't drop Ruby versions in anything but a major > > release so I'm being conservative and only going with the latest (at the > > time that was 2.2). > > > > I could be convinced to bring down the version number, but I'd like to > > know why first. :) > > Because other people are _always_ slow to upgrade :)
Yes, exactly. I am betting that by the time people upgrade to Rack 2.0, Ruby 2.2.2 will be old hat (Ruby 2.3 has been released already!) ;) > However, I suppose it's fine to bring the requirement up with a > major version bump of Rack. I don't want to burden you with > old cruft, either. > > unicorn may also be able to drop the dependency on rack by > lazy loading: > > * Rack::Utils::HTTP_STATUS_CODES is the main thing we use from > Rack at runtime; and unicorn would actually function fine if > the hash were empty; HTTP status lines would just be short > and non-descriptive. > > * The Rack::Builder dependency can be optional, even. > > Fwiw, I plan to support Rack 1.x and Ruby 1.9.3 under unicorn for a few > more years because of LTS distros. New versions take priority, of > course. Ok. Let me know if there's anything I can do to help. Removing the strict requirement from the gemspec *is* on the table, as long as we document the supported versions in the README. I don't plan on using anything that would be specific to Ruby 2.2.2 and up, but I don't want to be burdened by older ones either. A simple comment in the README would suffice. -- Aaron Patterson http://tenderlovemaking.com/
pgplCbQl4fnCz.pgp
Description: PGP signature
