Should I relax the version dependencies in gemspec, and use a narrower set for testing and certain publishings? That would allow more users to install it as a gem and make use of it,

Considerations

As of 0.9.1 and especially 0.10.1, Ronn-NG's gem dependency versions are defined rather tightly, to versions that I have actually tested on and know work. That seems good for when you're shipping Ronn-NG as an "application" that expects dedicated bundled/vendored dependencies. But not all targets may be able to supply those, especially in combination with dependencies from other Ruby-based programs that define their own gem version range dependencies, in distro environments that supply the dependency gems like nokogiri or mustache as their own distro packages, so they may have a fixed single "current" version.

Relaxation would look like this: set the minimum version for ruby and gem deps as low as I think I can go and have it still work (even with a couple issues), and don't cap the maximum versions or put exclusions unless I have actually seen issues with a that version. Then have a canonical set of dependencies for test runs and "tested well/known good" deployments, the way I use Gemfile.lock now. Would prob want a few different sets of them, for targeting different Ruby versions and/or downstream distros (which may ship only specific versions of dependencies). I don't know if there's a conventional Ruby/gems way of doing that. Maybe maintain a few different Gemfile.lock files in the repo, and switch between them with some symlinking?

Analysis

Downstream Linux packagers are patching gemspec to allow newer mustache versions, because they only ship >=1.0. (Fedora, Arch Linux.) And Debian patches gemspec to relax both mustache and kramdown & nokogiri in both directions.

References

• Related issues
  • RPM build failure on Fedora 39/Rawhide (bc nokogiri libxml "foo:colon" thing) #107