deivid-rodriguez/pry-byebug

Tighten dependency on pry

mvz opened this issue · 4 comments

mvz commented

The current dependency specification on pry allows any 0.x version starting from 0.10. Since pry is in the pre-1.x stage, please consider tightening the range of minor versions for this dependency.

deivid-rodriguez commented

I'm guessing this issue comes from the fact that pry 0.13.0 was released, and it's incompatible with the latest pry-byebug release, right?

I've had support for pry master for a while, so that particular issue can be fixed by cutting a new release of pry-byebug.

That said, I'm sorry this happened, and I'm happy to think of ways of preventing this in the future. How should I do that?

Possible ways:

  • Change the pry requirement to >= <min_version>, <= max_version constraint, and release a new version increasing the upper bound every time pry releases a new version? This seems like the most flexible option, but might require compatibility code to support several pry versions. I actually already have that kind of code in master so I guess it'd be fine for now 🤷‍♂️.

  • Change the pry requirement to ~> 0.y.z constraint? What should I do on new pry minors in this case? Increase the dependency to ~> 0.y+1.0 and drop support for the previous minor, right after every minor release of pry, even if it's compatible? This one seems viable, and maybe the easiest.

  • Don't change the requirement but make sure I release a new version of pry-byebug everytime there are breaking changes in pry's master. I'm currently tracking pry's master in CI, so this might be viable, but pry master seems too breaking at the moment, so I'll not do this.

I think I tend towards the second?

  • 👍1
mvz commented

I'm guessing this issue comes from the fact that pry 0.13.0 was released, and it's incompatible with the latest pry-byebug release, right?

Right :-)

Yes, the first two options were what I was thinking of. I think the first one requires more work, especially if you want to test compatibility with all minor supported pry versions. So, the second option may indeed be best.

  • 👍1
deivid-rodriguez commented

Ok, since I already have the compability code in master, I'll cut a release for now.

In addition to that, since I'm already tracking pry's master in CI, next time there are breaking changes in pry, I'll make a decision about this issue and change the requirement accordingly.

  • 👍1
  • 🎉1
deivid-rodriguez commented

I changed my mind, actually. I'll go with the second option, so that whenever pry releases a breaking minor in the future, I can add support at my own pace.

  • 👍1