556828 - Upgrade kohanaphp to latest stable

Status: RESOLVED WONTFIX

(Socorro :: General, task)

Description

[Laura Thomson :laura]

Currently 2.3.4

Comment 1

[Laura Thomson :laura]

There's now a stable 3 (3.0.4.2).  The entire API has changed (woo, rewrite) so I'm thinking we hold this (and the consequent bug 533489) for 2.0.

Comment 2

[Austin King [:ozten]]

(In reply to comment #1)
I agree. Until there are features that we really, really need in 3.0, this would be a timesink.

Comment 3

[Ryan Snyder [:ryansnyder] [:rsnyder] [:rysny]]

Kohana 2.4 is in beta and would be the only version I would recommend upgrading to once it becomes stable.  2.4 will be the last 2.x release.  From what I can tell, there's no reason to upgrade Kohana on SocorroUI to 3.0, even for the Socorro 2.0 milestone.

Comment 4

[Laura Thomson :laura]

We will go to 2.4 for 1.8 and then review when to go to 3.0 (perhaps for 2.0, perhaps after).

Comment 5

[Ryan Snyder [:ryansnyder] [:rsnyder] [:rysny]]

It turns out that Kohana 2.4 lacks Postres support, as does the default install of Kohana 3.0.

There is a Postgres module on Github, and its built for 3.0: http://github.com/cbandy/kohana-postgresql/

Moving to 3.0 is not in the cards at this moment.  Pushing this out to Socorro 2.0, which we can reassess at that time.

Comment 6

[Brandon Savage [:brandon]]

As a part of this, we need to investigate the handling of uninitialized or missing method arguments. Presently it appears that Kohana 2.x treats these as 500 errors, rather than allowing for us to intelligently handle these errors. See Bug #641902.

Comment 7

[Brandon Savage [:brandon]]

Per Laura, I spent time investigating the costs and consequences of upgrading Socorro to Kohana's latest (which is the 3.1.x series). I spoke with Ryan Snyder who had previously prepared an LOE, which he stated was roughly 1 month of work to remove all database logic to the middleware and upgrade the framework.

It appears that upgrading between the 2.x and 3.x series is akin to migrating to almost an entirely new framework. The model layer received significant changes, which would require a complete rewrite of most of the models. Postgres support is not offered in 3.x, though PDO is supported natively (it appears that the Postgres driver linked in Comment 5 is not supported for 3.1.x).

The controllers will likely fare better, but will still require extensive overhaul. Method names have changed, so all actionable methods must be prefixed with action_* in 3.x. Additionally, the naming convention has changed for classes, meaning that their relationship to the filesystem affects the class name (which is different from 2.x). The input library has been removed in favor of using the supergloabl arrays, which will require more effort from us to secure the system (and make our controllers less testable). 

Routes are now objects, and defined differently than in 2.x, meaning we'll need to migrate those over. Sessions also saw extensive reworking, so we'll need to make migrations there. There were few modifications in the view layer, which looks to reduce the overall impact in that area of the application.

It is my belief that it will take roughly 1 person 4 - 6 weeks to complete a successful conversion, plus time for security review and QA. This estimate is not dependent on whether the database logic remains in the frontend or is moved to the middleware.

Comment 8

[Laura Thomson :laura]

Brandon: put this on your priority list just behind the UI tweaks.