-
Notifications
You must be signed in to change notification settings - Fork 21.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove RecordTagHelper #18411
Remove RecordTagHelper #18411
Conversation
expected = %(<li class="record_tag_post" id="record_tag_post_45"></li>) | ||
actual = content_tag_for(:li, @post) | ||
assert_dom_equal expected, actual | ||
assert_raises(NoMethodError) { content_tag_for(:li, @post) } | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you can keep only 1 test for each method, should be enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I figured that would probably be enough, but I wanted to cover all the cases. I'll slim this down.
Public API changes should go through deprecation process |
@egilburg please read the discussion on the related issue, linked above. It's going to be extracted to a gem. |
@carlosantoniodasilva I did read about the gem extraction. In such cases, do we expect users to manually notice their app is broken (e.g. first time they get a runtime error) and add the gem entry, or would they get some runtime warnings first? I also do realize we have changelogs and upgrade instructions. But I didn't know there is a deprecation difference between code which requires a gem change from code that requires any other equally simple change (e.g. change method call signature somewhere in the app) |
The functionality will still be available for anyone who wants to use it. I don't believe people will just upgrade to Rails 5 and put their apps in production right away to see it blowing up. In short, this is pretty much the same we did with respond_to/respond_with and the responders gem, which is totally fine as long as there's an upgrade path imo. |
record_tag_helper should be live under /rails? |
We will have it under rails for now, as we generally do with other extractions at the beginning. |
Per DHH in #18337, ActionView::Helpers::RecordTagHelper has been extracted to an external gem (source currently lives at todd/record_tag_helper). Removal notices have also been added for anyone upgrading that use the extracted methods.
@todd could you transfer the repository to rails organization? I'll make sure you will have full access to it. |
@rafaelfranca I'm not an admin for the Rails org, so I can't transfer ownership to Rails. Can I add you as an admin on the repo and have you transfer ownership? |
@todd 👍 |
@rafaelfranca I added you as a collaborator, but I'm not sure if that grants you the ability to transfer repo ownership. It doesn't appear there's a way for me to edit your permissions on the repo beyond that. Let me know if we need to figure something else out. |
@todd 😅 I think you will have to transfer for me and so I can transfer for rails. |
@rafaelfranca Sheesh. Alright, done. 😛 |
You should have access to the gem. Thank you so much for working on this @todd |
@rafaelfranca My pleasure. What should the strategy/process look like for actually releasing the gem? |
We usually release it with the beta release of Rails. |
Ok, should I be responsible for that or will someone from the Core Team take the lead? Either way is fine, just trying to scope out my role moving forward. |
@todd I think for the first release it is better to us handle, but you will have access to push the gem too. |
👍 Sounds good. |
Since this is now out of Rails, it would be great to have a running version of the gem on RubyGems as soon as possible, for people who want to transition. To avoid squatting the |
* Since rails#18411, we started to inform about extracted gem (record_tag_helper) to developers who use `ActionView::Helpers::RecordTagHelper` 's methods. * Currently, it seems no problem that we don't have to support no longer.
Per DHH in #18337, I've extracted
ActionView::Helpers::RecordTagHelper
to an external gem (source currently lives at todd/record_tag_helper). I also added extraction notices for anyone upgrading who was using these methods - the corresponding code and tests should probably be fully removed at the next minor release after 5.0.0.Regarding the gem, I still need to write some documentation (the README is kinda sparse at the moment) and I'd appreciate someone else going over the code to make sure I'm not missing anything, though it seems pretty straightforward. There's also the question of whether the source for
record_tag_helper
should stay under my own account or get forked into the Rails org - I don't have a strong opinion either way. The answer to that question should also dictate who publishes the gem, so I'm holding off on pushing anything to RubyGems.