Closed gee-forr closed 1 month ago
Notice https://shopify.github.io/ruby-lsp/composed-bundle, where it says:
In addition to performing this setup, the composed bundle logic will also
bundle install
and attempt to auto-update theruby-lsp
language server gem to ensure fast distribution of bug fixes and new features.
Before hitting 1.0, every ruby-lsp
minor version bump means there's a breaking change. For example, 0.20
broke the interface for indexing enhancement. So if the upper bound wasn't there, this addon would lose its go to definition silently and could easily confuse users.
I currently aim at bumping up the limit within a week. Before that happens, bundler should simply lock your ruby-lsp
version to a compatible version.
Hey there @st0012 - thanks for the clarification. I was unaware that the ruby-lsp
was introducing breaking changes on minor version bumps.
We do indeed lock the ruby-lsp
in our gemfiles with a pessimistic declaration. My main reason for logging this issue was because I was unable to upgrade ruby-lsp
and ruby-lsp-rails
to new versions they've released recently, because ruby-lsp-rspec
required version 0.19.x.
At any rate - thank you again for this gem, and thanks for clearing up the reasoning - it's very much appreciated.
Hey there,
The dependency on
ruby-lsp
might be too strict.ruby-lsp
recently released0.20.x
, butruby-lsp-rspec
is configured to depend on it with the pessimistic operator set to0.19.0
, meaning any versions at0.20.x
or higher will cause a bundler error.Would it not make sense to rather pin a minimum version, and assume higher versions will not break backward compatibility? e.g.
spec.add_dependency "ruby-lsp", ">= 0.19.0"
, instead of the~>
dependency operator?I'm unfortunately not familiar with the internals of this gem or
ruby-lsp
so I might not be aware of how disruptive even minor version changes are?Either way - thanks for this gem :) It's helpful, and I really appreciate your contribution.