Just a little diversification of those use cases will be a great start… :)

I don’t know if this is the way you intended it to sound, but your sense of entitlement astounds me.

These people have created something amazingly useful – and given it away free for you to use.

A lot of developers hate to write documentation. Fine, but Kohana isn’t some project where the docs can be lacking. If you want developers to jump on board or evangelize Kohana at their jobs, you need to have a usable and comprehensive docs site. Comparing the docs for RoR or Django against Kohana is a joke. Sure, they’re larger projects, but how are we supposed to adopt a framework for our business when the learning curve for new developers is so high?

We’re going to continue using KO2.3.4 until KO3 hits some sort of truly mature release. IMHO, it seems like the development team needs to take this problem more serious.

Hop into #kohana on irc.freenode.net if you want to talk about it.

Thanks for the insight regarding the post. I really do applaud the effort you guys put in and I know the debugging process is quite painstaking in it’s own right.

I don’t believe there are necessarily problems with the Redmine reports themselves, but problems with sifting through them to find some information that should be fairly trivial. The reports are, in essence, a little too detailed and cover a number of issues and fixes which aren’t necessarily pertinent to what the majority of your users care about. Most users don’t necessarily need to know that you fixed bugs X, Y, and Z on your main page if they don’t inherently change a method’s initial intent or functionality. What they do need to know, however, is if you change a function’s parameters, return values, output, etc. Or perhaps if you deprecate a function or entire class in favor of a new method or class.

Redmine is perfect for the nitty gritty details when a developer catches wind of an apparent bug in the system. It does not seem to function as a good solution for supplying a summary of updates to classes and methods which affect the developer’s ability making system calls.

I hope this makes sense, as does my article. It’s purpose was to summarize what I believe to be some of the aspects that hinder Kohana’s growth as a framework. I can say I am in favor of a number of changes made in v3.x. While I’m at it, I might as well throw a request that you guys consider including the modules SwiftMailer and Message into your packaging system as they are two features I miss drastically from 2.x and took a little searching to find 3.x alternatives.