Release 2.17.0

[pirj]

---

Before submitting the PR make sure the following are checked:

• Feature branch is up-to-date with master (if not - rebase it).
• Squashed related commits together.
• [-] Added tests.
• Updated documentation.
• Added an entry to the CHANGELOG.md if the new code introduces user-observable changes.
• The build (bundle exec rake) passes (be sure to run this locally, since it may produce updated documentation that you will need to commit).

[bquorning]

Hang on 2 minutes while I set up branch protection rules ⌛

Update: Done!

[bquorning]

Do we coordinate this release with a v2.17.0 release of rubocop-rspec where the Capybara cops are removed?

[ydah]

[ask] Is there any need to change the author name of the license to match the gemspec?
https://github.com/rubocop/rubocop-capybara/blame/main/MIT-LICENSE.md#L3

rubocop-capybara/rubocop-capybara.gemspec

Line 14 in b775119

spec.authors = ['Yudai Takada']

But, I don't know if this is the proper way to handle a license for this kind of extraction.

[pirj]

branch protection rules

I messed up the main branch, it is main, not master like other repos. Or it was like this in a newly created repo, don't know.

[pirj]

IANAL, but I'd stay away from changing the license text unless absolutely necessary, even though I have no idea who is the person specified there now. We've extracted parts from the original code, and changing the original author feels like re-licensing.

[bquorning]

When I looked, there were no branch protection rules defined for this repo. I added the same required checks as in rubocop-rspec, only for the main branch and not master.

[ydah]

IANAL, but I'd stay away from changing the license text unless absolutely necessary, even though I have no idea who is the person specified there now. We've extracted parts from the original code, and changing the original author feels like re-licensing.

That is certainly true. It would be best to avoid that. Thank you.

[pirj]

Do we coordinate this release with a v2.17.0 release of rubocop-rspec where the Capybara cops are removed?

@bquorning Not necessarily. We can release rubocop-rspec 2.17.0 with all Capybara cops removed once rubocop-capybara 2.17.0 is released, but it doesn't have to happen the same or next day. And after that, releases can drift.

Is there a specific procedure after merging a PR like this, @bquorning ? I can imagine:

gem build
gem push
git tag v2.17.0
git push origin v2.17.0

[bquorning]

Is there a specific procedure after merging a PR like this, @bquorning ? I can imagine:

gem build
gem push
git tag v2.17.0
git push origin v2.17.0

bundle exec rake release does all of the above.

Don't forget to add another commit to main to change the antora config back to ~ after merging this PR. That’s probably the most confusing part of the release process.

[pirj]

@bquorning Invited you as an owner on RubyGems.
@ydah I couldn't find your email address. Send me something to pirjsuka@gmail.com
@Darhazer I tried inviting you, but it seems that the email you're using for RubyGems doesn't match the one in your GitHub profile/commits.

[ydah]

@pirj I sent it to your e-mail address 👍

[Darhazer]

@pirj I may use my hey e-mail nowadays, but the RubyGems is still Darhazer at GMail

[pirj]

@bquorning Do you happen to know what needs to be done to publish docs at https://docs.rubocop.org/rubocop-capybara?

[bquorning]

You need access to https://github.com/rubocop/docs.rubocop.org which currently only the rubocop-core team has. Perhaps @koic or @bbatsov can help, if they know GitHub permissions better than I do.

[pirj]

Thanks for the pointer, @bquorning, I've sent a PR rubocop/docs.rubocop.org#12

[koic]

I was late getting on this. IMHO, maybe RuboCop Capybara should have started with 1.0. Because starting with 2.x makes users wonder.
It may have been unnecessary to keep the original gem version as it goes through a new lifecycle as a new gem.

For example, 1.0 was the start when RuboCop Performance was extracted from the core. OTOH, RuboCop Rails started with 2.0 because of the gem name conflict. This was a tough choice:
toshimaru/rubocop-rails#31

[pirj]

I don't have a strong opinion here.
My reasoning for the initial version being 2.17.0 was to keep VersionAdded/VersionChanged unchanged.
I recall the case with rubocop-rails, and it makes me think that it was no big deal for the users to start with 2.0, no matter the reasons, was there?

As for rubocop-performance, the version 1.0.0 was published 14th of March 2019 when rubocop was at version 0.65.0, a pre-1.0 version, so every version mentioned in rubocop-performance's config/default.yml was still below 1.0.0.
This wouldn't be the case with rubocop-capybara, if we'd start with 1.0.0, we'd either have to:

• keep versions that are above 1.0.0 and even 2.0.0 in config/default.yml
• cap all versions in config/default.yml to be below 1.0.0, or set them all to be equal to 1.0.0

I don't think either of those two is an acceptable option.

Even though EnableNewCopsUpTo is not the case yet, it would break it, too by sneaking cops into unsuspecting user's configs.

[koic]

Yeah, VersionAdded will not be used since it's before rubocop/rubocop#8565 will be introduced.
Either way, RuboCop RSpec and RuboCop Capybara will have separate lifecycles. So I think it should be able to use different versioning management.

cap all versions in config/default.yml to be below 1.0.0, or set them all to be equal to 1.0.0

I was considering this option. However, it may not be worth reverting to 1.0 from current released version, It's up to you :-)
I understand your intent. Thank you for your explanation!

Since it has been released, 2.x seems to be fine. In short, as it is currently 😅

[ydah]

Should we release this GitHub repository?

[ydah]

Oh! It was released. Sorry 🙇‍♂
maybe the tag is cut but not yet released 🤔.