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
Kohana 3.3.1. Released!
  • Download available at: https://github.com/kohana/kohana/releases

    Official download from the website will be available soon.

    Changelog: http://dev.kohanaframework.org/projects/kohana3/versions/211

    Thanks @Zeelot3k and the whole Kohana development team!

  • Great ! Thanks ! (even if I still use 3.2, it's good to see some updates :))

  • Updates are coming for 3.2 too :)

  • Christmas in september ! :)

  • Yay, will be updating tommorow! Thanks!

  • @Zeelot3k: ermm.. that download link doesn't include the submodules, is that intentional?

  • it is not… hmm, github removed the "downloads" functionality and this automatic archive doesn't seem to work

    Edit: figured it out, give me a few minutes to fix this.

  • ok sorry about that… github lets you upload arbitrary files to releases so I've cloned the 3.3/master branch and removed any git related files and created an archive of it… just pushed the update to the download page to link to this archive so we should be good to go.

  • great work thanks!

  • Thanks everyone, great news!

    Note that in addition to the existing installation methods, from 3.3.1 onwards core and the official modules have composer.json files and Zeelot3k has registered them on packagist. So if you want to move away from git submodules to using composer it will be easier and faster than it used to be. Just add kohana/core etc to your project composer.json.

    The core (system) package will be installed under vendor/kohana/core - so you'll need to update your SYSPATH. Modules are still installed to the modules/ path.

  • I'm thinking of moving modules to vendor in 3.4.0 actually :) they don't actually make sense to be mixed into your own modules and it would be trivial to add a VENDORPATH or something similar. We probably should have had a conversation about this before adding the composer files.

  • That's not a bad idea - though in that case it might be sensible to get rid of the whole VENDORPATH/MODPATH idea and just reiterate the "everything's a module" concept and you pass whatever paths you want to Kohana::modules(). We bring in other (non-core) modules with our composer file and they're obviously not named kohana/anything but are still vendors - so it would be odd to have some under vendor and some under modules.

  • Yeah I mean the constants are just there to quickly get to a path. I don't really care what we call them :) maybe we can look at how to remove some of them as well.

  • @Zeelo3k,

    I mentioned this before, but wonder what is your opinion about that, K3.4 with:

    • stripper core, all HTML, Form, Cookie, Session, Feed and so on are moved to modules. Core is basicly only HTTP Delivery
    • Namespaces plus DI can be good enough as alternative to remove CFS. Thanks to DI we can inject proper class and switch HTML with our HTML

    After that K is smaller, faster, perfect for REST APIs, keeping it simple make K easier to maintain - K is Core, the rest are modules and can be released/updated separatly/later.

  • @thejw23 I would agree on moving HTML, Form to modules and removing Feed. But I would keep Session and Cookie because almost every application needs to be able to keep states.

  • @thejw23, personally I like DI, but I can't see how it can beat the simplicity of the CFS.

    For me, Kohana is basically HMVC + CFS.

    On the other hand, I do acknowledge that namespacing is hard to achieve with CFS.

  • By the way, thanks for the release

  • Is there a proper "roadmap" ticket for 3.4 ?

  • @Dave Not yet, I think. Development will focus on 3.2. as far as I know and only after that release we will start working on 3.4

  • Correct, the next focus is to get the final bugfix release for 3.2.x out. We need to take care of our released products before we focus on the API changes in 3.4.x. I will start making planning tickets for 3.4.0 soon.

    So take a look at our 3.2.x tickets :) http://dev.kohanaframework.org/projects/kohana3/issues?query_id=62 help us move on to 3.4 as quickly as possible.

  • @thejw23 "K is core, the rest are modules" -- Instead of making it into 3.4, I think it's better to make it on 4.x. Just keep 3.x concept as it is to maintain the compatibility.

    Anyway, thanks for releasing 3.3.1!

  • Maybe it's time to change release policy. With smaller dev team, longer periods between releases it's annoying to have two branches to maintain (3.2 and 3.3) - first one is quite old now (2011-07-25!), instead if releasing 3.2.x projects based on 3.2 could be migrated to 3.3.1 or left like they are now, without the update. What is the point of wasting time on releasing update to 2y old version? Kohana is having problems with development, releases are less frequent, dev team (in my opinion) should focus on pushing 3.4 and making it a modern framework (DI, less static/singletons...). This could bring new developers to Kohana, make development faster and releases more often.

  • @thejw23 Agreed, although there are a lot of common bugs between 3.2 and 3.3.1. If fixed in 3.2 those bugs could be merged into 3.3.1. too

  • Since 3.3.1 is out (right?), what's the point of releasing 3.2.x instead of focusing right now on 3.4 or 4.0 (there should be a roadmap what next)?

    Maybe there should be announcement on forums: hey people, we meet on IRC [date and time] to talk about K future. Pelase come and say what you want, what are your expectations, comment some of our ideas and help make K 3.4/4.0 better, a framework for 2014, an Swift alternative to S2/L4, maybe with some of their basic architecture ideas.

  • besides @Zeelot3k I don't really see any leadership around here. Everybody is trying to help in their own way, but doesn't really know what to do... unfortunate, but you're right we need to organize it better

  • Since 3.3.1 is out (right?), what's the point of releasing 3.2.x instead of focusing right now on 3.4 or 4.0 (there should be a roadmap what next)?

    We support the last two major versions, that's why.

  • C'mon, rules are for humans, not the other way. Do you really prefer fixing 2011 release rather than make Kohana 2014 friendly with 3.4/4.0 ? Since you don't have enough man power to make some changes, maybe it's better to use what you have for making Kohana beter instead of releasing another update for previous version... There should be a pool: do you want update for 3.2 or brand new 3.4?

    Please, think about changing this policy 'support for 2 major versions' - it was good at the time, but Kohana has slow down and this policy is slowing it even more.

  • We have a moral obligation to support it. The rules can change for later releases, but we said we'd support it, so we must support it.

  • I think zombor's right, and there are several of the remaining 3.2.x tickets that will also apply to 3.3.x and probably 3.4.x too. It would help to maintain community long term if we fix those against the oldest supported version and merge forward rather than bump them to a future version (where they'll still need to be done) just for the sake of it.

    That said, there's also some old 3.2.x tickets that seem to need more guidance on how core team want them resolved, and several with pull requests where it's not obvious what's blocking them.

    There's also a few that are feature requests, and I wonder if it's appropriate to close/punt those in the interests of getting moving forward?

    Including all of those, there's only 45 open tickets - if we just did a couple each we'd get there pretty fast.

  • I too think @zombor is right. It's a shame that @shadowhand didn't feel the same way.

  • but when Shadowhand was in the project it was under active development and it had some future. Right now it all slowed down, noone can be sure that 3.4 will be out in a reasonable time (since 3.3 was a bit later). I have nothing against DevTeam, they are doing it for free, I understand how it works.

    All I'm saying is: current release/support policy was fine back then, but is't no good for current development manpower.

  • @WinterSilence 3.3.1 is a minor release, 3.3 docs should cover it.

  • Thanks for your great work! I'm waiting for 3.2.3. :)

    With release 3.3.x was a discuss that is slower than 3.2.x. Can anybody make a performance test (simulate access from many users) between 3.2.2(or later 3.2.3) and 3.3.1? :)

  • Great news today! :)

  • Nice keep it up team! Looking forward for the major release

  • Nothing interesting to contribute, just a big thanks for the bug fixes, can see that you've done lots of work @Zeelot3k, thanks very much :)

  • Hi devs, how to update from 3.3.0 to 3.3.1? what folders shall I move from the 3.3.1? and what folders shall I retain in my old kohana folder?

  • @riz Replace system, modules (assuming you haven't modified it, which you hopefully haven't) and index.php. Obviously don't overwrite your application folder, because that's specific to your app.

  • Kohana

    I’m wondering about the future of Kohana. I can see that development has slowed significantly since I was last here (back in July 2010) and it seems the future of Kohana is being questioned more and more these days…

    At the same time, I see that the download page says that support for the latest version (3.3.1) will only last until November 2013! If I’m starting a new project today, where the development will last a couple months, what am I supposed to do/use?

    I first started using Kohana back in mid-2010. After trying CodeIgnitor I quickly switched to Kohana, built a site using 3.08, upgraded to 3.1 and now in present-day, it’s currently running 3.2.2. It runs very well, super fast, it’s easy to maintain and I have no complaints…

    The Kohana Framework made sense to me from the start. (I don’t use ORM, I setup my database with InnoDB tables, foreign keys, procedures, lots of triggers, etc. and I prefer to use my own queries.) The lack of documentation (as some people say) never bothered me either. The code is commented so well, (and all my code is commented like crazy too), that using the userguide module was, at least to me, better than having to read any documentation…

    In fact, I like Kohana so much that when I was writing a plugin framework for my WordPress site, I modeled it after Kohana somewhat… I’ve customized that WP site so much (custom plugin with various “modules”, custom theme, etc.) and I was about to customize it further (to change the way WordPress handles some things, and add some functionality) when it occurred to me that I spend so much time fighting WordPress (writing workarounds and hacks) that maybe it’s time to just move it off of WordPress already. I don’t need to tell anyone here how messy WordPress’ code is, slow, inefficient and cumbersome…

    So my situation is that rather than constantly fighting WordPress, I’ve determined that I should just use a framework and move the site off WordPress. Apart from moving some existing content though, you could say it’s a “new project”. In this case, I don’t mind starting from scratch and it probably makes the most sense to do so.

    And once that’s done, my original Kohana site is also due for a makeover. I have a lot of changes I need to make to that site (that have been pending for a while now) and I’ll be adding a lot of new functionality (and integrating Stripe) at the same time.

    So the question is, what framework should I use?

    Though I used to make a living as a web developer (to support myself while going to college for music), I’m not a full-time developer (music is my day job) so I don’t have tons of time to learn “various” frameworks. While that investment in time makes sense for a full-time web professional, in my case, I prefer to learn one framework very well than to use many of them poorly. The problem is, I have a love affair with Kohana that’s hard to split away from, but at the same time, I don’t want to invest all my time with Kohana if the framework is eventually going to die, which seems like very much a possibility. Or am I wrong? Is this rut just a temporary thing with a foreseeable end in sight?

    I’ve started looking into Laravel, Rails, even Django, though not very thoroughly by any means. Staying with PHP has its pros and cons just like moving away from HMVC or Kohana’s cascading file system will be a tradeoff… I’m not in a huge hurry though, so I do have some time to spend if I have to learn a new framework (or new language like Ruby or Python) first. What would be the best way to invest my time? (Of course, in a perfect world, I’d just spend my time focusing on music and hire a web developer, but that would take web development away from me, which is a “hobby” that I actually enjoy…)

    My emotions and stubbornly-loyal self say to just use 3.3.1 and have some faith, but my instincts tell me that starting a project where the framework’s support will end mid-way though development (November 2013) is a terrible idea. Given the considerable investment in time I’m about to make (with both of these projects), hopefully you can understand my need to proceed with caution.

    So, what’s the future of Kohana looking like? Am I better off jumping ship now? And if so, if you used to LOVE Kohana and have since moved away to a different framework, what has your experience with said framework been like?

    Thanks!

    DM

  • New release is out. Closing this thread.

This discussion has been closed.
All Discussions

Howdy, Stranger!

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

In this Discussion