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.
On Tue, May 17, 2016 at 1:43 PM, Prathamesh Sonpatki <[email protected]> wrote: > 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 <https://github.com/prathamesh-sonpatki> | | BigBinary > <https://BigBinary.com> > > On Tue, May 17, 2016 at 10:09 PM, Hiren Mistry <[email protected]> wrote: > >> 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]> 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]. >>>> 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. >>>> >>> -- >> 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. >> > > -- > 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. > -- 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.
