Make Rubocop-RSpec compatible with Rubocop v1.0

[bquorning]

Update: With the release of v2.0.0.pre, this issue has been closed. Please notice that you may need to manually edit your Gemfile to have this version installed.

---

RuboCop v1.0 has been released, and RuboCop-RSpec is not compatible. It is expected that the compatible version will be released as RuboCop-RSpec v2.0.0, which will also contain a number of other major changes.

This milestone tracks the work that needs to be done: https://github.com/rubocop-hq/rubocop-rspec/milestone/1

I’d like to tackle this in two steps, one after the other:

1. Compatibility with new RuboCop
2. Code removal and other non-backwards compatible changes.

Please help me identify which PRs in the milestone belong to category 1 and which belong to 2.

I would like to test things out in another branch than master. Which, given that all current pull requests are against master means that I must merge and test locally. Why? I would like to have some certainty about the direction before we start merging code and I would like to keep the master branch clean in case we need to push a bugfix release before we’re ready to release v2.0.

[bquorning]

/cc @pirj @Darhazer @marcandre

[bquorning]

Hmm, actually I think (1) may just be #1019 and a couple of fixes to default_config_spec.rb.

[pirj]

That is very reasonable.
You may actually change the target branch of pull requests for 2.0 to e.g. release-2.0

Hmm, actually I think (1) may just be #1019 and a couple of fixes to default_config_spec.rb.

I think this is correct.

[bquorning]

You may actually change the target branch of pull requests for 2.0 to e.g. release-2.0

Ooh nice, I didn’t know that. I’ll do that for our open pull requests on the 2.0 milestone.

[bquorning]

Actually, after merging #1019 we could release a v1.99.0 that would be compatible with RuboCop 1.0, while we work on the remaining PRs in the 2.0 milestone.

[jesperronn]

Actually, after merging #1019 we could release a v1.99.0 that would be compatible with RuboCop 1.0, while we work on the remaining PRs in the 2.0 milestone.

Considering semver versioning, I don't think it makes sense to throw in a high 1.x number.

The two options I see for version numbering is:

1. compatibility with Rubocop 1.0 (and no breaking changes). This would be the next available 1.x version (patch or minor)
2. compatibility with Rubocop 1.0 (and breaking changes). This would be next available major version (2.0.0)

Considering the description in #1019:

* Update RuboCop dependency to v1.0.0. ([@bquorning][])
* **(Potentially breaking)** Change namespace of several cops (`Capybara/*` -> `RSpec/Capybara/*`, `FactoryBot/*` -> `RSpec/FactoryBot/*`, `Rails/*` -> `RSpec/Rails/*`). ([@pirj][], [@bquorning][])

Given this is potentially breaking, then I suggest calling it 2.0.0.

I really love the idea with a release ASAP to support Rubocop 1.0. So call it 2.0.0 and not 1.99.

After that, the rest of the works you listed, could go into v3.0.0.

In my experience, better safe and release an extra major version. I bet you will not run out of major version numbers 👍

Thanks for your efforts, guys ♥️

[pirj]

release a v1.99.0 that would be compatible with RuboCop 1.0, while we work on the remaining PRs in the 2.0 milestone.

@bquorning Let's try that, I really hope this works. I also hope we won't postpone 2.0 for too long after that.

Just let me know if you need a hand with anything related to those releases.

So call it 2.0.0 and not 1.99

@jesperronn If we release a version with RuboCop 1.0 support and dropping < 1.0 support, plus cop renamals, and call it 2.0.0, then introducing more breaking changes in 2.0.1 is not an option according to SemVer, it should be numbered 3.0.0.
There's nothing that prevents us from changing the dependency version and renaming cops in a minor version, so I fully support the idea of 1.99.
It's a transit version number, similar to RSpec 2.99, and really means "it's actually a version 1.45, but it's also the latest 1.xx version we plan to release".

[bquorning]

I agree that by releasing breaking changes in a v1.99, we wouldn’t be following semantic versioning. People who rely on semantic versioning might just run bundle update and would now see breaking changes (and rightfully start complaining about it).

But we are not going to release a v2.0.0 followed by a v3.0.0 in a few days. That would be confusing for everybody, and only be beneficial to those who are impatient to try out RuboCop v1.0 (myself included).

I can think of two other options:

1. You can tell Bundler to install from our release-2.0 branch, or
2. We can release a v2.0.0-beta1 which I guess allows for breaking changes between it and v2.0.0. https://semver.org/#spec-item-9 says

A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92, 1.0.0-x-y-z.–.

[pirj]

releasing breaking changes in a v1.99 ... would now see breaking changes

Do you mean those who don't use rubocop directly in their Gemfiles, but do use rubocop-rspec? Sounds like a rare case.

For the rest, who have both rubocop and rubocop-rspec, wondering what Bundler decides, to go with rubocop 1.0 and rubocop-rspec 1.42, or rubocop 0.9x and rubocop-rspec 1.44.1? We've introduced ~> 0.87 just recently, it was > 0.87 prior to 1.43.

[pirj]

I support the idea of releasing 2.0.0-pre with just the basics to support RuboCop 1.0, and a full 2.0.0 release with the rest.
I'm just against releasing 2.0.0 without all the rest of the changes that we planned for 2.0.

[jesperronn]

I acknowledge that you already planned for a bigger 2.0 release. However, it is probably relevant to even more people to be able to upgrade to rubocop to v 1.0. For my personal and work project I will consider to delete rubocop-rspec dependency until rubocop 1.0 is supported, since it is more important for me to upgrade rubocop than to upgrade rubocop-rspec.

This is also why I think you should release a version ASAP that supports Rubocop 1.0.

Personally I prefer you call it v2.0 but if you call it something else, it will still work for me. Also if you plan a new release with even more changes, I would be totally fine with calling next version v3. Breaking versions could be days apart.

I also think it eases upgrade if you release breaking issues as individual majors (even if they are released within a very short timeframe).

However, the above is just my personal opinion. There is a more important case for community: To support Rubocop v1.0.

If youguys can agree on a plan, then I will support whatever decision you make. Thanks for working on the project, I really appreciate it ❤️

[marcandre]

Isn't it possible to have a default_v1.yml file and use that at runtime depending on the check of RuboCop's version? This way you can issue a 1.x version that would be compatible with all versions of RuboCop and you are free to release 2.0 (that could be compatible with all RuboCop or >=1 only, your choice) at your leisure?

[pirj]

Isn't it possible to have a default_v1.yml file and use that at runtime depending on the check of RuboCop's version?

Ha. It slipped my mind we're actually in control of that [1, 2].

@marcandre No worries, 2.0.0.pre is out, and we're working hard towards a 2.0.0 release. We've been preparing all pull requests in advance, just didn't merge them into a single pull request, since we weren't sure when RuboCop 1.0 was going to happen. And it happened very suddenly! :D

2.0.0.pre is usable for the majority of our users already.
2.0.0 will contain API changes that would only affect third-party cops and extensions based on rubocop-rspec's internals.

[pirj]

To be fair, this process is manual ATM, since bundle update doesn't have a --pre flag, and it ignores 2.0.0.pre altogether unless you explicitly specify 2.0.0.pre in the Gemfile. 😬

[bquorning]

With the release of v2.0.0.pre, I am closing this issue. Please beware that you may need to manually edit your Gemfile to have this version installed.

[bquorning]

RuboCop RSpec 2.0.0 has just been released. 🎉