Comments

Leave a response

1. Ramses on 04 Jan 22:24:
   

   Hmm, that :gzip option looks interesting! Think the web server is going to like this. ;)

2. Jay Feldblum on 04 Jan 22:30:
   

   Heroku currently injects configuration code into vendor/plugins to configure your application for the Heroku platform. Other deployment systems do the same. For example, Heroku injects a plugin to disable x_sendfile, and another plugin to set Rails.logger to log to $stdout.

   If vendor/plugins is to be phased out, how should Heroku and other deployment systems inject configuration code? An initializer?

3. AstonJ on 04 Jan 23:13:
   

   Thanks!

   Anyone know where the .mobi guides are?

4. AstonJ on 04 Jan 23:29:
   

   Found here: https://github.com/rails/rails/blob/master/railties/guides/source/kindle/KINDLE.md

   But running KINDLE=1 rake generate_guides (or rake generate_guides) says: Don’t know how to build task ‘generate_guides’

   Any ideas anyone?

5. Lukas Fittl on 04 Jan 23:38:
   

   @Jay Feldbaum

   These systems run “bundle install” on the server anyway – simply make it a full-blown gem and patch it into the Gemfile.

6. AstonJ on 04 Jan 23:58:
   

   Ok got it – I’ll submit an updated how-to later on tonight.

7. hipertracker on 05 Jan 00:23:
   

   $ ruby -v ruby 1.9.3p0 (2011-10-30 revision 33570) [x86_64-darwin11.2.0]

   $ gem -v 1.8.13

   $ gem install rails—pre ERROR: Error installing rails: actionpack requires journey (~> 1.0.0.rc1)

8. Santiago Pastorino on 05 Jan 00:44:
   

   Jay Feldblum: an initializer is fine.

   hipertracker: if you run gem install rails—pre again do you still get the same error?, doesn’t make any sense actionpack requires journey (~> 1.0.0.rc1) and journey 1.0.0.rc4 is available, so Rubygems should pick that one

9. hipertracker on 05 Jan 01:40:
   

   Santiago Pastorino: I get the same error. To solve it I had to install “journey -v 1.0.0.rc1” and then “gem install rails—pre”. I don’t know why actionpack wants 1.0.0.rc1. I removed all gems ant that’s true: ‘gem install journey -v ”~> 1.0.0.rc1” ’ installs 1.0.0.rc4 …

10. AstonJ on 05 Jan 03:31:
    

    Ok here’s the step-by-step if anyone needs it: https://github.com/rails/rails/pull/4312/files

    Awesome .mobi version of the guides btw – nice work Michael & Xavier!!

11. prabesh708@gmail.com on 05 Jan 07:18:
    

    What to update in your apps section is the best inclusion for this blog. I hope to see this section in every release .

12. Jon on 05 Jan 14:07:
    

    All green here so far. Yes, the “What to update in your apps” is very helpful. Great job, Rails Team.

13. german on 05 Jan 15:42:
    

    While installing 3.2.0.rc2 I have the same error as hipertracker, so I opened an issue here: https://github.com/rails/rails/issues/4317

14. liang.gimi@gmail.com on 06 Jan 17:29:
    

    One more update step:

    Update your Gemfile to depend on coffee-rails ~> 3.2.1

15. Rob Morris on 06 Jan 19:57:
    

    Re: deprecating vendor/plugins – what is the thinking for those of us who have plugin-based architectures where we are actively developing multiple full-stack plugins with cross-plugin dependencies?

    Having to rebuild/rebundle my gems and restart my dev server each time I change a view in an engine seems like a massive workflow pain point, relative to the current seamless reload.

    Thoughts?

16. Flip Sasser on 24 Jan 03:36:
    

    I second Rob’s question. The “engine” functionality is completely central to a workflow we have in place, as we need to replicate both our models and our models’ unit tests across three separate repositories.

    I’d love it if we could keep some of the dynamic reloading fun from engines, although I recognize the need for a consistent solution to loading third-party libraries.

17. Brad on 25 Jan 23:19:
    

    +1 on @Flip Sasser and @Rob Morris’s comments

18. jim on 01 Feb 19:59: