[IMPORTANT ANNOUNCEMENT] Transfer rubocop-rails gem to RuboCop Team

[toshimaru]

⚠️ANNOUNCEMENT⚠️

As I and RuboCop team( @bbatsov, @koic ) discuss in rubocop/rubocop#5976, I decided to give up rubocop-rails gem to RuboCop team.

✈️ Transfer Path

• Create another gem to replace the rubocop-rails gem.
  • https://github.com/toshimaru/rubocop-rails_config/releases/tag/v0.1.0
• Create a migration version which announces the replacement of the gem name in post_install_message.
• Add new owners of the gem (It'll be @bbatsov and @koic )
• Remove my ownership of the gem

💭 Others

• It'd be better to yank older versions after rubocop-rails gem is reborn.
  • yank old versions

[matthewd]

It'd be better to yank older versions after rubocop-rails gem is reborn.

I'm not sure how much benefit that gives, vs breaking everyone's ability to install historical bundles that have included the gem under its old name. 😕

---

As for the new name: I suggest we consider rails-rubocop, moving it to be a semi-official Rails project, if you're interested.

[bbatsov]

I'm not sure how much benefit that gives, vs breaking everyone's ability to install historical bundles that have included the gem under its old name. 😕

@matthewd The version scheme of the new gem is obviously going to be different, so yanking all those releases would be best. I realize this is unfortunate, but I don't really think it's going to be particularly painful.

As for the new name: I suggest we consider rails-rubocop, moving it to be a semi-official Rails project, if you're interested.

It'd be better to adopt some more meaningful naming scheme for such gems - e.g. rubocop-rails-config or rubocop-rails-profile. RuboCop plans to support profiles out of the box soon, so something like this will likely just be bundled with it in a few months (the profiles would give you the option to use a different base config depending on your preference).

[toshimaru]

@matthewd, Thanks for your proposal!!

Currently, I'm going to name the gem rubocop-rails_config. This naming idea is same as @bbatsov.
https://github.com/toshimaru/rubocop-rails_config

I'd say rails-rubocop does sound good for semi-official Rails project, but rubocop-rails_config sounds better for renaming rubocop-rails name. 🤔

[toshimaru]

Migraion version v1.5.0 has been released.

[toshimaru]

Have yanked old versions except for v1.5.0. https://rubygems.org/gems/rubocop-rails/versions

[toshimaru]

@koic @bbatsov I've just added you guys to the owner of the gem!! Thank you for waiting 😺

[bbatsov]

@toshimaru Thank you!

@koic I guess now you can start with the extraction process.

[koic]

@toshimaru I confirmed that. Thank you for processing it!

@bbatsov Sure! I will go ahead with extracting Rails department from RuboCop Core.

[veelenga]

@toshimaru yanking old gems breaks bundle install on a lot of projects. Why not to leave it for backward compatibility? You added a usage warning to this old gem though, which is a good enough indicator to upgrade/switch to the new (maintained) gem.

The version scheme of the new gem is obviously going to be different, so yanking all those releases would be best. I realize this is unfortunate, but I don't really think it's going to be particularly painful.

@bbatsov since we still have rubocop-rails 1.5.0 on the RubyGems, I guess we could be able to have the older releases without problems?

[bbatsov]

@veelenga I was actually planning for the initial release to 0.9 (or lower) and eventually yank 1.5 as well. Otherwise the version schema would get pretty confusing (you get one gem with one version and another gem with a different version).

It's a pity we won't be able to have rubocop-rails 1.0, but it is what it is. It would have been nice if rubygems had some way to just eradicate a yanked versions completely.

[toshimaru]

@veelenga It was tough decision for me. The gem functionality is going to be totally changed and it's going to be a big surprise for rubocop-rails users. I think telling them about the rename of the gem is as important as not breaking the build. Generally speaking, rubocop is used in development environment, so I would say yanking gem doesn't break production build. That's why I gave the priority to the announcement and yanked the gem.

@bbatsov I'd be nice if we use gem push --force (like git push -f), but there's no such command... 😞

[nbibler]

Not to muddy the waters, but I can't see a reasonable rationale for yanking old versions of a library which work and are not a security concern.

If the direction is to rewrite the library to behave differently, why name it the same? It's not the same, right?

If the concern is that developers won't know there's a completely new version of a new library that behaves entirely differently, wouldn't it instead be better to release a new version of this library with a deprecation message? That message could contain a link to details about the new library, the reason for the change, the benefits, and maybe even upgrade guide, eventually? Which, I guess this was the intended direction with the 1.5 release... ?

Not that I think it can be fixed now, but yanking the old versions forces all projects to immediately update (because new project devs can't bundle install existing projects, you can't install a yanked version) and it interrupts developers from doing whatever their other task might've been in order to address this issue right now. That can be gotten around by just removing the gem entirely from the project dependencies.. which I imagine is more likely what will happen in the short term.

This seems like an explicit attempt to circumvent semantic versioning and I'm not seeing any good rationale or benefit to be had in exchange for that.

[koic]

@toshimaru I'm currently in the process of extracting RuboCop Rails from RuboCop Core.

I have a question. When can rubocop-hq/rubocop-rails use rubygems.org/gems/rubocop-rails?

That means the timing when the content of rubocop-rails gem changes.

[toshimaru]

@koic

When can rubocop-hq/rubocop-rails use rubygems.org/gems/rubocop-rails?

The last release(v1.5.0) with deprecation message has been release on July and I've yanked the older gems(refs. #31 (comment)), so I'd say it's nice timing to use rubocop-rails gem for rubocop-hq/rubocop-rails.

When you release the brand-new gem, Bumping major version would be good ideas, so the next version will be v2.0.0.

[koic]

@toshimaru I see. Thanks for your kindness.

[koic]

@toshimaru RuboCop Rails 2.0.0 has been released. Thank you again for your kindness.
https://rubygems.org/gems/rubocop-rails/versions/2.0.0

[toshimaru]

@koic Great job! 🎉

Since 2.0 has been released, I'm going to archive this repo and make it read-only. Any issue or concern?

[koic]

Thanks. rubocop-rails 2.0.0 and 1.5.0(.rc) are different gems. By that, the following issue is opened.
rubocop/rubocop-rails#56

If possible, yanking 1.5.0 (and 1.5.0.rc) may reduce user confusion in the future. However, I'm worried about not knowing whether almost all rubocop-rails 1.5.0 users has migrated to rubocop-rails_config.

[toshimaru]

yanking 1.5.0 (and 1.5.0.rc) may reduce user confusion in the future

True.

1.5.0 users has migrated to rubocop-rails_config

Much time has passed after the v1.5.0 release, so I think yanking gem is not a bad decision. (As far as I know. 🤔)

---

Any opinion about this? @anyone

[bbatsov]

I agree that archiving this repo and yanking the older releases is the best course of action.

[toshimaru]

Thanks @bbatsov , I've just yanked outdated versions (1.5.0 and 1.5.0.rc).

I think this should be my final work as an ex-maintainer of rubocop-rails.

@koic Could you drop my ownership of the gem? After my ownership is dropped, I'll archive this repository.

[koic]

@toshimaru I removed your account from rubocop-rails gem owners. Let's keep hacking rubocop-rails_config. Thank you!

[toshimaru]

Thank you, all. let me close this.

---

P.S.
created an issue about making the gem official. (cc/ @matthewd )
toshimaru/rubocop-rails_config#51