Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relax prism version constraint #266

Closed
gmcgibbon opened this issue Feb 15, 2024 · 5 comments · Fixed by #297
Closed

Relax prism version constraint #266

gmcgibbon opened this issue Feb 15, 2024 · 5 comments · Fixed by #297
Labels
dependencies Pull requests that update a dependency file

Comments

@gmcgibbon
Copy link
Member

Right now, we have an upper-bound version constraint on Prism here:

spec.add_dependency("prism", ">= 0.18.0", "< 0.22")

It looks like the original reason for this was to prevent a breaking change from affecting RBI in 2abfa69. In practice, this works well in the moment, but when applications need to specify a new version of Prism, they can't (because RBI is being strict for seemingly no reason).

This seems to have caused more strain on maintainers of RBI to release a new version for every version bump of a dependency, and that doesn't make sense. Can we relax this dependency to either:

  • Remove the upper-bound entirely, and expect maintainers of Prism to fix unintended breaking changes with subsequent releases.
  • Restrict to the next major version (1.0), and trust Prism to introduce breaking changes intentionally with a major version bump.

I'm asking because I got bit by this while testing a patch on Packwerk that's attempting to use Prism.

@vinistock
Copy link
Member

Prism might still go through breaking changes in the Ruby API while the team works to integrate it with the Ruby compiler. We can't relax the constraints until the API is stabilized or we risk breaking rbi on a minor release from Prism.

We're waiting for confirmation from the team working on Prism that the API is stable and then we can relax the constraints and use major versions as the indicator of breaking changes.

@andyw8
Copy link
Contributor

andyw8 commented Feb 20, 2024

But might this also be an indication that we don't have full confidence in rbi's tests? Would improving those help to mitigate the risk of breaking changes?

@vinistock
Copy link
Member

I don't believe that's the case. We do have confidence in the test suite, but if we relax the constraint people will be able to upgrade Prism and break RBI regardless of the tests.

Imagine this scenario:

  • We relax the constraints to be prism < 1.0.0
  • A breaking change is released in Prism v0.26
  • Someone runs bundle update prism
  • RBI will break after the update for end users, regardless of our test suite

@Morriar Morriar added the dependencies Pull requests that update a dependency file label Mar 1, 2024
@andyw8
Copy link
Contributor

andyw8 commented Apr 11, 2024

Closing as we still want to restrict the Prism version while there are breaking changes. Hopefully not for too much longer.

@andyw8 andyw8 closed this as not planned Won't fix, can't repro, duplicate, stale Apr 11, 2024
@rafaelfranca rafaelfranca reopened this May 2, 2024
@rafaelfranca
Copy link
Member

rafaelfranca commented May 2, 2024

We should allow users to use any new version of prims they want, so they can report bugs (or not) to us. By restricting them we are artificially restricting what they do based on the possibility of anything breaking.

If there were a security bug in prism, we would be the ones restricting people from upgrading. This isn't a good solution long term, and it is false sense security.

If we are worried about prism breaking API, let's run CI every day with the main branch of prism to make sure we fix the problem before the release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies Pull requests that update a dependency file
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants