Improve user feedback in rails update [Feature Request]

[Hiren Mistry]

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).

[Rafael Mendonça França]

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?

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-co...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

[Hiren Mistry]

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

[Prathamesh Sonpatki]

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.

./prathamesh

 GITHUB | | BigBinary

[Pedro Nascimento]

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.