To not having to match exact tiny versions of all dependencies for big apps.
We should approach each upstream and make them promise they will follow Semantic Versioning. rubygems.org issue for allowing SemVer compliance field.
"If tiny version change is allowed, we can surely keep minor versions updated in debian and major versions can be embedded if those cannot be synced." - Praveen
"I would love it would work that way. But it’s a dreamworld. Start out by looking at how many of our dependencies are at 0.x.y, even following ?SemVer, you’re allowed to break everything with any release in that period, regardless of version number.
Now ignoring that fact, it assumes people don’t make mistakes. But they do, they release broken things in patch versions. Support for new major versions of other dependencies is added with just a patch release. Keeping an unspecific dependency graph of this size in a compatible state while allowing the most broad version requirements is a fucking full time job. We opted to actually be able to develop diaspora* further in our time and test against only two exact graphs specifically. Anything that breaks the exact graph, we cannot, will not and should not support." - Jonne Haß
Positive
active_model_serializers (like ?SemVer even though it is 0.x)
sentry-raven - kind of, mostly
kaminari - kind of, mostly
- octokit (already mentioned in README)
- omniauth (already mentioned in README)
Negative
sidekiq - negative, it will never be supported
compass-rails - (bug closed without any explanation)
httpclient - will try, but no promise
rack-oauth2 - closed without reply, dropped ruby version support in a minor update
toml-rb - closed without reply