Re: [Rails-core] Improve user feedback in rails update [Feature Request]

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

On Tue, May 17, 2016 at 1:43 PM, Prathamesh Sonpatki 
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  | | BigBinary
> 
>
> On Tue, May 17, 2016 at 10:09 PM, Hiren Mistry  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  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 ).

 --

Re: [Rails-core] Improve user feedback in rails update [Feature Request]

[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


On Tue, May 17, 2016 at 10:09 PM, Hiren Mistry  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  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 ).
>>>
>>> --
>>> 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.
>>>
>> --
> You 

Re: [Rails-core] Improve user feedback in rails update [Feature Request]

[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



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

-- 
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-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit 

Re: [Rails-core] Improve user feedback in rails update [Feature Request]

[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?

On Mon, May 16, 2016 at 1:00 PM Hiren Mistry  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 ).
>
> --
> 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-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> 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 rubyonrails-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

[Rails-core] 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 ).

-- 
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-core+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-core@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.