Versioning request.

[JonRowe]

Hello!

Your friendly neighbourhood RSpec team here, we've noticed that the latest version shift for diff-lcs is breaking our builds as we introspect on the diff contents, we are working on this and are confident that it is just a semantic issue for us, but I noticed in the course of reading the new readme, that you are intending to hard drop more Ruby versions in the next version, totally understandable, we intend to do that in our next major version too.

What I've come here to request is that your next version, or any version with hard Ruby version changes, be 2.0, as we and probably others have specified < 2 for some time, being the next expected major version, so we were hoping to avoid breaking changes.

You are of course, completely within your rights to say "no, thats not our versioning system" however it is impossible for us to back date the change to "< 1.5" which means that bundler will try to install both new versions of diff-lcs and old versions of RSpec on potentially incompatible Rubies, and cause people problems, so I'm hoping you will agree that releasing a 2.0 next will be a smoother path for everyone!

Thanks for your work!

[halostatue]

diff-lcs follows SemVer-ish (I don’t use an explicit third digit until required). The release of 1.4 was not supposed to be a breaking change for any version of Ruby. I see your report under #63 and will be fixing that issue. Please feel free to tag me on any issue in rspec failures because of diff-lcs with older versions.

The hard drop of unsupported Ruby versions won’t be until diff-lcs 2.0; the soft drops have mostly been because of CI availability. If I introduce code which causes failure on those versions as tested by users using those versions, I will either (a) revert the change or (b) rework the change until it works with the specified version. With the exception of modern symbol hash specification, I think I write code that is syntax compatible with Ruby 1.8 for the most part, and for libraries that I support that still have 1.8 in their permitted list, I avoid that.

The format changes are to fix long-standing bugs (see #6 and #22; I haven’t verified that these are explicitly fixed by these most recent changes, but at least some of the incorrect diff output has been fixed). diff-lcs output (as expressed through ldiff) has always considered that the output of diff is the canonical correct form. That said, as I do consider rspec a primary “client” of diff-lcs, I am willing to consider the following options, should the case be made for either:

1. Release 1.5 that reverts some of these changes to keep format compatibility and release 2.0 that contains these changes (and makes the hard drop of old Ruby versions); or
2. Add some code—possibly during the require-phase rather than runtime—to detect that we are being loaded by an incompatible version of RSpec and revert the changes to that.

The latter is going to be harder, but I think is the correct choice. I’ll need some assistance from the RSpec team to have branch tests once I start that (I don’t want to release versions that partially apply this), and we can remove that check on a 2.0 release.

[JonRowe]

Apart from the older Ruby issue, the format changes are probably bug fixes and I'm ok with RSpec handling this within our spec suite, we are matching on exact diff output so bug fixes are going to overly affect us of course, but we've had to make no outside facing changes, it's just our own build, we're adding support for testing 1.3 and 1.4 until we release RSpec 4, we'd probably add an env run for 2 if needed, but with the major release we'd set our minimum to 1.4 or 2 if released and drop the differences in the test suite.

[halostatue]

I believe that #64 will fix the tests for RSpec on pre 2.0 versions of Ruby, and I’ve asked if you can do some testing with the branch so that if there any other issues we can hash them out there, so I’m going to close this. I will try to remember to open an issue on RSpec for future releases.

Is there a roadmap/timeline for RSpec 4? I should also be looking to have tests that run against RSpec 4 since this is my only gem that uses RSpec.

[JonRowe]

Theres no concrete roadmap other than "in 2020" as I want to release before Ruby 2.7/3 due to the er... pain of the keyword argument changes, I'm also working on some parallel testing code that I'd like to make the front runner feature of RSpec 4, as otherwise it's going to be solely a "drop Ruby release"

[halostatue]

OK. I haven’t even started playing with Ruby 2.7 because of those changes, but I suspect that most of my code is unaffected by them because I’ve had gems that have promised support for some fairly old versions (this is what happens when you’re an old-timer like me).

Different question to consider: do you and the RSpec team want to take ownership of diff-lcs? I have ideas and plans to rewrite it so that it’s completely MIT-licenced (basing it on older, original PD sources or re-forking it from a more open stance), but I’m too busy and am mostly using Elixir these days for work (I’m still writing a lot of Ruby, but it’s sidecar applications and support scripts). The good news is that, especially with these format changes being resolved, the only thing that really should be required is keeping the CI versions up-to-date.

[JonRowe]

I don't feel I have the knowledge or bandwidth to look after it with the attention it deserves, I know @benoittgt looked at building a custom differ for us as diffing everything as strings is not ideal for us, maybe give it its own organisation and look for volunteers to help maintain it? @benoittgt any interest?

[halostatue]

If I do hand off diff-lcs, it will definitely be in its own organization. My problem is that I also don’t really have the bandwidth to give this project the attention it deserves.

[benoittgt]

Hello @halostatue and @JonRowe

Thanks for the ping. I have the feeling that working on diff-lcs will be maybe not the right choice for RSpec. As mention in rspec/rspec-support#365 (comment) a new differ should be dedicated for RSpec. A differ that handle RSpec semantic.

Thanks for bringing this subject on the table. I should spend time on it. :)