DHH once said the major advancement that Rails provided was empty folders, just a standard place to put things. Any app I go to, I can immediately find the assets, models, etc. In the same vein, I would support shipping with a staging environment. In my ideal world there would be a way to inherit production settings into my staging env, where I could just over-ride them as needed (with a different DB by default).
I was introduced to the concepts of test/develop/prod environments as I was learning Rails. I think that was a good thing. Now that i'm teaching Rails, I make sure to introduce students to the concept since it is so useful. I agree that we can go overboard by providing a million default environments out of the gate and that would be bad. Though most good Rails applications i've seen have had a staging environment and server set up, and I believe that vanilla Rails should promote good practices. I also agree that configuration shouldn't be stored in source at all, and for those in the thread asking why that is, I think 12factor covers it fairly well http://www.12factor.net/config . I personally like to keep any of my server access tokens, secrets, and connection strings in environment variables, but there are still elements that I set inside of the config files. It would be killer to move Rails towards a source-control-less configuration setup. Even then, I would support having some support for a staging environment out of the gate. Getting outside of implementation, what are the downsides from users/maintainers to having this functionality in `rails new` ? -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/Qm_kZxGPsEcJ. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
