TIP: Use Markdown or, <pre> for multi line code blocks / <code> for inline code.
These forums are read-only and for archival purposes only!
Please join our new forums at discourse.kohanaframework.org
Upgrade from 2.3.x to 3.1.0
  • Howdy,

    I would like some inside look from the people who were upgrading it's Kohana 2.3.x applications to Kohana 3.1. Is it worth it? How much effort do you need to put into migration. What are the main problems you experienced. Is there anything that will not work and will need a redesign?

    I have couple of applications on Kohana 2.3.x, some with 3 and more years of development and are actually still evolving with new features, etc... It runs stable on 2.3.x. Should I even migrate? And always when I start a new project I say to my self I will finally go with Kohana 3.1... But on the end I always end up going with 2.3.x which I'm very familiar with.

    Thanks, Jie

  • It's basically a rewrite of your code. Heavy migration and redesign.

  • Oh that bad :S? That would take me forever. Not worth it then... Guess I will be stuck with 2.3.x until I find time of learning 3.1.

  • You should however start any new projects with 3.1 :)

  • @zombor

    You should however start any new projects with 3.1 :)

    I don't find this to be very true... I am a long time 2.3.x developer and have couple of successful pages running out there. I was doing my first 3.1. install just for a test because I would love to switch to new Kohana... But I find that really painful. The lack of good documentation and tutorials. It's just impossible to find how Auth works. Even ORM has very limited documentation. There is completely no information on how to setup multi-language website and no code examples or even project skeletons that would put some real-life good practices into usable code. I mean it's ok if you have lots of time for playing around. But some of us actually make living by realizing real projects and have very little time for learning framework yet once again... and that is a framework that we already know... well at list I thought I knew :).

  • Cool, stick with 2.3.x then - sounds like you've found your framework

  • This is exactly how this community will be fragmented and never grow bigger.

  • @k03n00b And your experience in relation to this is ... what? Telling people to always use the latest version will cause nothing but pain. There's no good reason why a website built on Kohana 2.3.x should attempt upgrading to 3.1.x, just for the sake of upgrading.

  • I do not recommend to always upgrade to latest version of Kohana, it certainly is pain in the brain.

    I have done one big migration from 3.0.9 to 3.1.1 and that's probably the last time I do that, but there's a good reason why I did migrate... That's because I have to stick/stuck with one Kohana version for a long time (few years) and wanted the recent one (new features etc.).

    Why do I have to stick with one version?

    Because I need modules that are reusable between different projects and I need compatibility between newer and older projects, because otherwise I can't directly use my new modules in my older projects.

    This very same reason is why community can't grow too much, because there's only few who has so much time (or skills ;) that they could upgrade their existing library of modules every time API is broken. Or maybe they just won't upgrade (add features to) their older projects, then there isn't any problem.

    One solution would be creating everything with pure PHP, but then you lose many benefits of having framework.

    Just a thought, no hard feelings...

  • Being backward compatible is always a though decision. For the type of work I so, I'm happy Kohana isn't backward compatible. However, I do understand how some wish it were for the re-usability of modules.

  • There could be an optional "compatibility layer", added on top of Kohana, that could also help to upgrade, for example, by logging calls to deprecated methods. Sort of this:


    public static function instance()
        Kohana::$log->add(Log::NOTICE, 'Deprecated method call ... from ...');
        return Request::initial();

    Just a thought though. Certainly not absolutely necessary, but might make someone's life easier.

  • Yeah we could, but that would be bloated and more maintenance work for us. No need for those sorts of things to be there. Also, making a "compatibility layer" for something like the validation changes would be a nightmare, in addition to the fact the Request/Response would be impossible to "emulate" like that.

  • What do you mean by nightmare? It's true, that I haven't yet taken a good look at the new sources, but I imagine it shouldn't be that hard. All it needs to do is some mapping to methods and properties that has been moved around.

    For example, validation filters would just add a corresponding rule on top of the rules array, callback just add rules. Request could capture setting properties in a magic method and pass it to appropriate methods of its response object.

    Not saying it can't get tricky, but someone could try it and release as a module.

  • thats more work than i thought

    because any API's has been changed, partially without a reason,

    an expl. is I18N --> it is now wo grouping feature

  • What do you mean by nightmare?

    I mean it's a maintenance nightmare. There's no need for it.

    but someone could try it and release as a module.

    Why bother, just copy the old validation class into your own module/application. Boom, 100% compatibility ;)

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion