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

Rails 5.1.0.beta1 deprecation #257

Closed
CvX opened this Issue Feb 24, 2017 · 1 comment

Comments

Projects
None yet
2 participants
@CvX
Contributor

CvX commented Feb 24, 2017

Rails 5.1 deprecates ActiveRecord's changes and other related methods (e.g. attribute_changed?). See: rails/rails@16ae3db and rails/rails@ef993d3

Here's one of the warnings:

DEPRECATION WARNING: The behavior of `attribute_changed?` inside of after callbacks will be changing in the next version of Rails. The new return value will reflect the behavior of calling the method after `save` returned (e.g. the opposite of what it returns now). To maintain the current behavior, use `saved_change_to_attribute?` instead.

Deprecated use in this gem is here:
https://github.com/swanandp/acts_as_list/blob/master/lib/acts_as_list/active_record/acts/list.rb#L396

It's the only one that popped up in my app, but there may be some other deprecated methods in use here.

What's the strategy for handling such deprecations?
respond_to?("#{position_column}_before_last_save") … else …?

@brendon

This comment has been minimized.

Show comment
Hide comment
@brendon

brendon Feb 24, 2017

Collaborator

Hi @CvX, thanks for bringing this to our attention :)

I like to branch based on Rails version in cases like these because that's the determining factor, and the core reason why we're branching. It helps later on when we go to remove support for older Rails versions as we don't then have to figure out when/why the change was implemented.

An example:

Would you like to implement this and modify the Appraisals and travis.yml files? (Remember to run appraisal install to update the individual appraisal files.)

Collaborator

brendon commented Feb 24, 2017

Hi @CvX, thanks for bringing this to our attention :)

I like to branch based on Rails version in cases like these because that's the determining factor, and the core reason why we're branching. It helps later on when we go to remove support for older Rails versions as we don't then have to figure out when/why the change was implemented.

An example:

Would you like to implement this and modify the Appraisals and travis.yml files? (Remember to run appraisal install to update the individual appraisal files.)

@swanandp swanandp closed this in 177740f Feb 27, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment