Improve user feedback in rails update [Feature Request]

Hi,

I would like to present a feature request to the rails rails:update command. This feature request is about user experience and making developers lives better. It goes alongs the same lines as your recent migration from rake to rails, which has been an absolute joy to use, much, much more than something that runs a fraction of second faster.

I think it would be really nice if the rails update command provided more user feedback for files that it does not update. Some examples:

  1. if it printed out in STDOUT that I should change the data-turbolinks-track from true to reload in my application.html file because it wasn’t able to find the application.html.erb file. (I used HAML, SASS, and Rspec in my rails app.)
  2. code in cable.coffee has changed and needs to be replaced with cable.js.
  3. mention there has been additions like config/initializers/ssl_options.rb and config/initializers/to_time_preserves_timezone.rb files, but it’s not needed for my application because… (post a link to refer to) and that’s why it did not create them.
    Basically with better feedback, we can save all the developers time and anxiety when upgrading. With a little feedback like this, dev’s know there are additional changes that needs to be done that the script wasn’t able to, or new things/configuration changes with reference links to research so they can determine what they wish to do about it. When upgrading becomes easier and pleasant, then more dev’s will be willing to upgrade quicker which results in less support for older versions.

Regards,

Hiren.

PS - I got this insight from my recent experience updating rails (see issue #24983).

Hi,

For what I could see in your explanation you are expecting the update task to teach people about the changes between some pre-releases. I don’t think it is sustainable to do that. I’m all for improving the update task to give better feedback when do a minor version upgrade.

I believe we have almost all this information in the upgrading guide, so do you think that a link to the upgrade guiding after the command finish would be a good way to improve the process?

Hi Rafael,

I’m not expecting much for pre-releases as they are a work in progress. My feedback is for checking these cases before final release (time/priority/resource permitting). I agree the ideal solution presented above is not sustainable for an open source project, but I wanted to put the idea out incase there are some easy wins.

To your suggestion of adding the link to the upgrading guide in the console output, absolutely do it - I think that’s a super, super easy way of informing people. I can help with adding that in if you can point me to the file and area.

The next level would be to inform the user of which files did not get changed or were partially changed. It doesn’t need to be complex, I’m thinking the script knows if a file was changed or not, so if we can capture the unchanged files and list them that’s a start. Then printing something like this for my scenario:

The following files were not updated, please refer to the upgrade guide for changes and if it’s applicable to you:

  • application.html.erb
  • cable.js
  • ssl_options.rb
  • to_time_preserves_timezone.rb

``

There may be other more simpler solutions of basically informing the user that rails update took care of these changes but these other ones were left out and you need to look into it. It greatly lowers the barrier to checking the upgrade guide by giving the user very tangible things to focus on.

I appreciate you listening to my idea and I do understand the situation from your side in adding features. Let me know if you need me to help with adding the link for now.

Regards,

Hiren

We can definitely talk about the files which we remove specifically for older apps, like the ssl_options initializer or to_time_preserves_timezone.rb.

It’s certainly a good improvement to have a cleaner guide on Rails itself, but I’ve had some success using http://railsdiff.org/. It looks like http://railsdiff.org/5.0.0.beta3/5.0.0.rc1 would have helped you figure out what changed between the betas and the rc1.