ChiliProject is not maintained anymore. Please be advised that there will be no more updates.

We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.

Upgrade to Rails 2.3-latest (Feature #196)


Added by S C at 2011-02-15 05:55 pm. Updated at 2011-05-06 10:46 pm.


Status:Closed Start date:2011-02-15
Priority:Normal Due date:
Assignee:Eric Davis % Done:

0%

Category:Libraries
Target version:2.0.0
Remote issue URL:http://www.redmine.org/issues/6887 Affected version:

Description

Since it would fix several security risks and fix rubygems 1.5 related issues (#133) it would be good to plan a migration to the latest Rails version.


Related issues

blocks Feature #216: Remove the rubygems hack from boot.rb Closed 2011-02-22
blocks Feature #217: Remove the hack to require a specific i18n version in boo... Closed 2011-02-22

Associated revisions

Revision d2931534
Added by Eric Davis at 2011-05-07 12:44 am

[#196 #216 #216] Complete the upgrade to Rails 2.3.11

History

Updated by Felix Schäfer at 2011-02-15 06:13 pm

Eric, I can't remember if we had talked about this already, but Holger and I think we should upgrade rails to 2.3-latest for 2.0.0. That would correspond with the deprecation of the old i18n syntax, but I suppose someone would have to go through all the views to check for strings that should and shouldn't be h-ed. What do you think?

Updated by Eric Davis at 2011-02-15 11:48 pm

I was thinking about using 2.3-latest for ChiliProject 2.0 also.

ChiliProject 1.x will need to stay on 2.3.5.

Updated by Felix Schäfer at 2011-02-16 01:44 pm

Eric Davis wrote:

ChiliProject 1.x will need to stay on 2.3.5.

Indeed.

So what would we need at least to get to 2.3.11? Change the interpolation format in the i18n files, throw out some of the "evil hacksâ„¢" needed for the older stuff to work with the newer gems, what else?

Should we create a feature branch for that?

(and just so that I don't forget: the rails_upgrade might help lessen the pain with transitioning to 2.3-latest and especially 3 after that)

  • (deleted custom field) set to http://www.redmine.org/issues/6887
  • Target version set to 2.0.0
  • Subject changed from Upgrade to Rails 2.3.11 to Upgrade to Rails 2.3-latest

Updated by Eric Davis at 2011-02-17 12:47 am

Felix Schäfer wrote:

So what would we need at least to get to 2.3.11? Change the interpolation format in the i18n files, throw out some of the "evil hacksâ„¢" needed for the older stuff to work with the newer gems, what else?

  • i18n changes
  • hardcoded gem requirements
  • standard rails update (e.g. JS files, script/*)

It would also be good to review the commit logs to see the details of the changes. Rails 2.3.5..Rails 2.3.11

Should we create a feature branch for that?

Yes, but it should be off of unstable once we release 1.1.0.

Updated by S C at 2011-02-17 08:11 am

Maybe we could divide it in sub-tasks (when it's time to work on it, not now) so we can share it so you don't get everything on your shoulders ;)

Updated by Felix Schäfer at 2011-02-17 08:31 am

Simon COURTOIS wrote:

Maybe we could divide it in sub-tasks (when it's time to work on it, not now) so we can share it so you don't get everything on your shoulders ;)

Absolutely, though I think we should wait until 1.1.0 is out. After that I'll create the additional branches on github and make new issues.

Updated by S C at 2011-02-17 08:32 am

Sounds good to me :)

Updated by Eric Davis at 2011-02-19 01:23 am

As long as you don't create subtasks here. Their implementation isn't complete and have some pretty nasty side effects that are hard to reverse.

Updated by S C at 2011-02-19 02:30 am

What do you mean by "not here" ?

Updated by Eric Davis at 2011-02-19 03:26 am

Simon COURTOIS wrote:

What do you mean by "not here" ?

Sorry. "As long as you don't create subtasks on chiliproject.org"

Updated by S C at 2011-02-19 12:40 pm

Why ? Migrating to a new version of rails is a multi-step process and dividing it in atomic tasks seams the better way to manage it. Isn't the Issue system made for this kind of situation ? Creating tasks and organizing them with relationships ? Tell me if I'm wrong, I just want to understand your point of view :)

Updated by Tim Felgentreff at 2011-02-19 01:24 pm

Simon COURTOIS wrote:

Isn't the Issue system made for this kind of situation ?

Yeah, but actual subtasks (the implementation of them on Redmine and thus Chili) are still kinda broken so we shouldn't use them until we fixed that code. You can of course just open new top-level issues for the organizational subtasks and just refer to this one.

Updated by S C at 2011-02-19 01:25 pm

Ah ok, that's what I had in mind :)

Updated by S C at 2011-03-02 08:17 am

FYI, redmine trunk is now using Rails 2.3.11 so it should not be too difficult to migrate to it too.

Updated by Eric Davis at 2011-03-18 05:50 pm

I'll be upgrading Rails when I review the latest Redmine commits (#288).

  • Assignee set to Eric Davis

Updated by Eric Davis at 2011-03-18 05:56 pm

  • Category set to Libraries

Updated by Eric Davis at 2011-04-16 11:47 pm

This has been added to unstable in 0e789c5 but I want to do a review of it to make sure everything was upgraded by comparing it to the files in a fresh rails 2.3.11 application.

Updated by Eric Davis at 2011-05-06 10:46 pm

I merged the files from a fresh Rails app into ChiliProject. d293153

  • Status changed from Open to Closed

Also available in: Atom PDF