search

rubocop / rubocop-capybara

Code style checking for Capybara files.
https://docs.rubocop.org/rubocop-capybara
MIT License
41 stars 8 forks source link

Release 2.17.0 #2

Closed pirj closed 1 year ago

pirj commented 1 year ago

Before submitting the PR make sure the following are checked:

bquorning commented 1 year ago

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

Update: Done!

ydah commented 1 year ago

[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 https://github.com/rubocop/rubocop-capybara/blob/b7751197e265de646421f5015588a36b97431060/rubocop-capybara.gemspec#L14

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

pirj commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

@pirj I sent it to your e-mail address :+1:

Darhazer commented 1 year ago

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

pirj commented 1 year ago

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

bquorning commented 1 year ago

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 commented 1 year ago

Thanks for the pointer, @bquorning, I've sent a PR https://github.com/rubocop/docs.rubocop.org/pull/12

koic commented 1 year ago

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: https://github.com/toshimaru/rubocop-rails/issues/31

pirj commented 1 year ago

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:

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 commented 1 year ago

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 commented 1 year ago

Should we release this GitHub repository?

ydah commented 1 year ago

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