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 On Monday, May 16, 2016 at 9:26:29 AM UTC-7, Rafael Mendonça França wrote: > > 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? > > On Mon, May 16, 2016 at 1:00 PM Hiren Mistry <[email protected] > <javascript:>> wrote: > >> 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 <https://github.com/rails/rails/issues/24983>). >> >> -- >> 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 [email protected] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> Visit this group at https://groups.google.com/group/rubyonrails-core. >> For more options, visit https://groups.google.com/d/optout. >> > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
