Jean Boussier <[email protected]> wrote: > >> I don't really see any reason to protect against newer Ruby version. > > > > I do: Ruby does not have a good track record when it comes to > > maintaining backwards compatibility. > > Regardless, preventing the gem installation before the version even exists > cause massive pains to people trying to do the good thing of testing their > app against ruby master. > > Until it is known that compatibility is broken, restricting the ruby version > causes more harm than good. Just this morning I had to submit patches > to a dozen gems.
That sucks. Perhaps adding warnings about untested+unsupported versions to test_helper.rb and extconf.rb is a better way to go? (nothing annoying at runtime after it's installed, though) Then, maybe leave the version check out of the gemspec entirely. Fwiw, the type of breakage from incompatibilities I'm worried about is subtle things that don't show up immediately (e.g. encodings, hash ordering, frozen strings, etc...). Stuff that obviously breaks at startup is preferable (e.g. I added some 1.9 symbol hash keys to signal the move away from 1.8). Thanks. -- unsubscribe: one-click, see List-Unsubscribe header archive: https://yhbt.net/unicorn-public/
