Vít Ondruch wrote:

Is there planned migration to Rails 3?

Yes, but not Rails 3.0, see further down.

As I am seeing mentioned ChiliProject 2.x on some places, it seems to me that it should be right time.

We're thinking about making a major release earlier than currently planned (current plan says august IIRC) to switch to rails 2.3-latest and use bundler/gemfile for dependencies, as well as to begin defining dependencies for currently included third-party gems/libs.

Also, there are claims in FAQ that it is not possible as long as Rails 3 do not support Engines, but this is not true IMO: http://api.rubyonrails.org/classes/Rails/Engine.html

It is not only a claim but also a fact: the rails 3 "Engines" are nothing nearly as powerful/integrated as the currently used ones and would require big changes to the way plugins are handled. IIRC you'd already have to go through some hoops and loops just to know what project your object is in, and so on.

All in all: switching to rails 3 won't happen on rails 3.0, we're waiting to see what 3.1 brings and will make a decision then.

That's sad. I am asking because there is interest to prepare RPM packages of Redmine/ChiliProject for Fedora, but Fedora 15 is going to be shipped only with Rails 3.

You could bundle rails 2.3-latest to ChiliProject.

You cannot bundle/vendor anything in Fedora. That is the policy. Yes, I know, it has some drawbacks but also some advantages.

Vít Ondruch wrote:

You cannot bundle/vendor anything in Fedora. That is the policy.

Well, then you couldn't currently include ChiliProject anyway as almost everything but RMagick and rails is bundled.

It can be "debundled" of course ...

Vít Ondruch wrote:

It can be "debundled" of course ...

Which does not help with rails3 issue, it seems that redmine/chilli will not be included in Fedora 15 unless one of them is able to run on rails3. However, F13/F14 are still using "good" rails and required work (remove bundled gems/plugins/whatever & packaging) should be done for those versions as it will take much longer time than switching redmine/chilli to rails3.

How about adding support to Apotomo and Cells to ChiliProject? Lots of the things possible with the old Engines are also possible with Apotomo/Cells. Besides that, I think that Rails 3.1 will make it possible to turn ChiliProject or Redmine in a mountable engine/application. This mean we could, for instance, have a Gitorious install with ChiliProject mounted on gitorious.org/chiliproject. Of course, several other projects would benefit from being able to install ChiliProject as a mountable app. That would be wonderful!

Maybe there is some student interested in doing that for a GSoC or RSoC...

Rodrigo Rosenfeld Rosas wrote:

How about adding support to Apotomo and Cells to ChiliProject?

We've been looking at cells a little bit for the mypage blocks, the sidebar, maybe wiki macros, and generally to see what is possible with them, the bulk of the work we currently do is directed at other places for the moment though. If you have experience with them, It'd be great if you could share your ideas or even soup up some proof of concepts :-) (in a new thread though so as to no hijack this one)

Lots of the things possible with the old Engines are also possible with Apotomo/Cells.

We're not looking at alternatives to the engines for the moment. We have enough on our hands on the moment that we can wait to see how the rails 3 engines evolve in rails 3.1, and if they are useable for us, we'd like to keep them to keep the upgrade barriers as low as possible. If when rails 3.1 comes out the engines still aren't useable for us, we'll look for alternatives, that's just not the case for the moment, but thanks for the input :-)

Given that rails 3.2 RC is now out, is there an agreed approach to handle the engines problem ? (edit to correct as RC)

Simon Stearn wrote:

Given that rails 3.2 RC is now out, is there an agreed approach to handle the engines problem ? (edit to correct as RC)

That's the Next Big Problemâ„¢ that needs tackling indeed.

I don't think that keeping an as-is compatibility for existing plugins will be (reasonably) doable, so I think we'll have to move on and figure out the least painful way by experimenting with it on the way.

Regarding the roadmap, I sadly have to admit that we don't have a clear path yet, though I'll have (or hope so) some more time next week to think about this and talk about it with Holger and Eric. The goal is pretty clear though, I don't want to pave the helpers and views with safe_html calls until everything kinda works but to really construct everything we need correctly. I expect this to be a big part of the required grunt-work. Same for the assets: don't just mindlessly copy them over to the asset pipeline dirs but work out how to best use it. And so on.

The modus operandi will probably be: get the tests running with rails 3.1 or 3.2 (the later might be too much of a challenge…), and everyone picks its favorite set of views/controllers/other code, treads through the code, gets the tests running and looks for other things that might need fixing. I should be able to post more on this in the next few weeks.

Anyway, thank you very much for your interest and we'd be thrilled if you were able to help once we've fleshed the path out.

Redmine will support rails 3 in the version 2.0.0 http://www.redmine.org/issues/4796
Is there any roadmap to support it in Chiliproject? How often Chiliproject is synchronized with Redmine?