The EY team will maintain 1.8.x branch only for security issues, I don't
think they will backport all the 1.9.x features. Because it's a non-sense.
The present (not the future) of Ruby it's 1.9.1, honestly don't know why the
majority (myself included) is still on the old-and-beloved 1.8.6.
The
I see sublime elegance in having the DB store the DDL to revert
migrations. I haven't worked with large teams in years, but I see the
dilemma Steven is addressing:
The common DB is at Rev N
User (or branch) A migrates common DB up to Rev N + 1
User (or branch) B is checked out and expects
The present (not the future) of Ruby it's 1.9.1, honestly don't know
why the majority (myself included) is still on the old-and-beloved
1.8.6.
Our primary reason is because none of the main hosting services
support 1.9. EngineYard, Rails Machine, etc. all are still on 1.8.6.
We are
On Wed, Sep 9, 2009 at 2:48 PM, Chad Pytelcpy...@thoughtbot.com wrote:
The present (not the future) of Ruby it's 1.9.1, honestly don't know
why the majority (myself included) is still on the old-and-beloved
1.8.6.
Our primary reason is because none of the main hosting services
support 1.9.
You can safely use Passenger with Ruby 1.9.1, avoiding REE.
- Luca
--
lucaguidi.com
twitter.com/jodosha
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups Ruby
on Rails: Core group.
To post to this group, send email
On Wed, Sep 9, 2009 at 3:36 PM, Luca Guidiguidi.l...@gmail.com wrote:
You can safely use Passenger with Ruby 1.9.1, avoiding REE.
I wasn't asking whether you can use Passenger with 1.9.1. I'm talking
the about these REE announcements on the passenger (sorry, 'Phusion')
website:
On Wed, Sep 9, 2009 at 5:03 AM, Chris c...@hapgoods.com wrote:
I see sublime elegance in having the DB store the DDL to revert
migrations. I haven't worked with large teams in years, but I see the
dilemma Steven is addressing:
The common DB is at Rev N
User (or branch) A migrates common
Since database.yml gets ERB'd, I've seen a trick where the database name is
lazy evaluated w/ the output from a git branch command. This way each
branch has a seperate DB. There is a bit of manual work involved to make
sure you create the database each time you create a new branch, but that's
On Wed, Sep 9, 2009 at 12:17 AM, Yehuda Katz wyc...@gmail.com wrote:
Hey Jeremy,
I apologize for the delay.
The basic idea is that there are a number of issues in Ruby 1.8.6 that are
simply not going to be fixed
(see http://svn.ruby-lang.org/repos/ruby/tags/v1_8_7/ChangeLog for a
complete
This line o' code in autosave_association.rb is a little bit weird
imo.
attribute = #{reflection.name}_#{attribute}
Line 252 on master at the moment.
It's used in at least two places I can tell (I haven't looked very
hard), accepts_nested_attributes and validates_associated. The string
that
On Wed, Sep 9, 2009 at 1:33 PM, Jeremy Evansjeremyeva...@gmail.com wrote:
On Wed, Sep 9, 2009 at 12:17 AM, Yehuda Katz wyc...@gmail.com wrote:
Hey Jeremy,
I apologize for the delay.
The basic idea is that there are a number of issues in Ruby 1.8.6 that are
simply not going to be fixed
Hey Josh,
I think this patch by José Valim, which is in my queue to work on this
week, will solve this problem for you:
https://rails.lighthouseapp.com/projects/8994/tickets/2904-avoid-copying-errors-from-child-to-parent-on-autosave
Cheers,
Eloy
On 9 sep 2009, at 19:36, Josh wrote:
This
I think if we don't go to ruby 1.9, ruby and rails will get stuck in a
similar thing that happened with java 1.2 1.4 and 1.5.
Come on guys, these are all open source projects. If something isn't
working on a newer version, how much work would it be to get it to
work?
just my 2cents
On Wed,
On Sep 9, 2009, at 2:54 PM, Jeremy Evans wrote:
On Wed, Sep 9, 2009 at 2:32 PM, Joris Verschoor
jbversch...@gmail.com wrote:
I think if we don't go to ruby 1.9, ruby and rails will get stuck
in a
similar thing that happened with java 1.2 1.4 and 1.5.
Certainly, supporting the latest
On Wed, Sep 9, 2009 at 5:54 PM, Jeremy Evansjeremyeva...@gmail.com wrote:
On Wed, Sep 9, 2009 at 2:32 PM, Joris Verschoor jbversch...@gmail.com wrote:
I think if we don't go to ruby 1.9, ruby and rails will get stuck in a
similar thing that happened with java 1.2 1.4 and 1.5.
Certainly,
Doesn't this same problem exist always - whether you are going down or
up, or store your migrations in files or the database? Some would
consider it an antipattern to put any models or app classes in your
migrations.
Some would be wrong if they considered that an anti pattern ;). The
vast
On Wed, Sep 9, 2009 at 6:31 PM, Michael Koziarskimich...@koziarski.com wrote:
Doesn't this same problem exist always - whether you are going down or
up, or store your migrations in files or the database? Some would
consider it an antipattern to put any models or app classes in your
Come on guys, these are all open source projects. If something isn't
working on a newer version, how much work would it be to get it to
work?
I'm not sure if you're being sarcastic here, but I'll bite. It's very
often quite a bit of work. It's even more work to then maintain 1.8.6
and
Has anyone tried installing the mysql gem from Rubyforge on 1.9? It's stuff
like that that makes people hesitant to switch to 1.9. Projects on Rubyforge
who's owners have long abandoned it. There needs to be a way for other
people to patch gems and submit them and have a team of dedicated people
On Wed, Sep 9, 2009 at 4:02 PM, Rick DeNatale rick.denat...@gmail.com wrote:
My normal practice when writing migrations which depend on model code
is to put a migration specific model clase in the migration file
itself, scoped inside the migration. The model mimics a subset of the
one in
20 matches
Mail list logo
