And the Rails Tutorial book (http://www.railstutorial.org/)
has again been updated:
s/2\.3\.6/2\.3\.7/
I hope this doesn't start happening every day. :-)
I'm working through your tutorial, and I really -- really -- love it! Thanks for the work you put into it.
One thing though. Although it's great that you keep versions updated, perhaps you should mention that Heroku only supports rails version up to 2.3.5? As a total beginner, it took me a few hours to realize why I got strange errors when deploying...
Another reader mentioned the Heroku issue as well; sorry it caused confusion. I'll check it out and get back to you. If it continues to be a problem, I suggest moving back to 2.3.5 for now.
Update: It works if you add an explicit gem requirement to RAILS_ROOT/.gems:
rails --version 2.3.8
My hope is that Rails 2.3.8 will Just Work™ on Heroku at some point; I have an email in to them to see if they expect this to be the case.
Heroku does support Rails 3 (3.0.0beta). I ended up porting my stuff from 2.3.5 -> 3 and was up and running in no time at all. See http://docs.heroku.com/rails3 for more info.
(Without meaning to sound callous to folks who have been reduced to firefighting this week: with sane practices on applying updated libraries to production, it happens to other people.)
This is why I fix the versions on ALL my gems to a known good version. Updates can only happen by changing that version in my source. Tests will be run after that, of course. I'm pretty sure it's standard practice now, but I can't believe there was a time when I didn't do this.
Just 2 days ago, a new version of authlogic was released that accidentally broke 2.3.5 compatibility. And that's a respected and widely used gem. It happens. Also, many gems are starting to deliberately break rals 2.3 compatibility - their newer versions are rails 3 only. Not to mention that gem authors sometimes deprecate and then obsolete some interfaces. So if you're not fixing your versions yet, and you don't have "sane practices" for updating them, it's time to start.
This is the main reason I think we need distributions (in the Debian sense) of gems. It needs to be ok for the gem authors to go ahead and break compatibility if they need to. App maintainers also need to know that they are safe unless they choose to opt in to breaking changes. A distribution would act as the go-between.
If you've got sane library management processes, you're pretty much safe, but that's a huge amount of wasted effort - everybody has to figure it out for themselves. Right now, it's downright dangerous relying on upstream gems directly unless you know exactly what you're doing, and a distribution layer would let everyone share a common knowledge about which gem versions go well together.
It would also give a handy insertion point for backporting security fixes, which currently doesn't happen very often.
