I'm having a similar issue. unicorn:restart doesn't seem to be reloading the unicorn process at all. However nothing to do with the assets, the actual start time on the process doesn't change.
Ryan can correct me if I'm wrong, but CanCan is designed to give permissions to different user groups in your app, where Rollout is to help you slowly roll out features, so at some point 100% of the intended users will be using the feature.
Here is an example
Lets say that GitHub had a cool feature they want to release on the homepage.
Think how many millions of developers are on GitHub and would use the new feature on a homepage right away, and if that feature had a bug, you have millions of issues to fix (caused by this 1 bug).
However, if you rolled out the feature to only 1 persent of the millions of users, you'd limit the bug and any issues that are raised from the bug to only 1 person of millions!.
Also, they could then open the feature to 25% of the users and see how the new feature effects performance. Once they are sure that 25% of traffic has stable performance, they can bump the feature to 50% of the users, and so on.
I'm having a similar issue. unicorn:restart doesn't seem to be reloading the unicorn process at all. However nothing to do with the assets, the actual start time on the process doesn't change.
Thanks for taking the time to explain this, it's always nice to see all the options and how it affects the http header. Keep up the good work!
Ryan can correct me if I'm wrong, but CanCan is designed to give permissions to different user groups in your app, where Rollout is to help you slowly roll out features, so at some point 100% of the intended users will be using the feature.
Here is an example
Lets say that GitHub had a cool feature they want to release on the homepage.
Think how many millions of developers are on GitHub and would use the new feature on a homepage right away, and if that feature had a bug, you have millions of issues to fix (caused by this 1 bug).
However, if you rolled out the feature to only 1 persent of the millions of users, you'd limit the bug and any issues that are raised from the bug to only 1 person of millions!.
Also, they could then open the feature to 25% of the users and see how the new feature effects performance. Once they are sure that 25% of traffic has stable performance, they can bump the feature to 50% of the users, and so on.