I’ve got a bone to pick with the Kohana development team. I just wasted a couple hours out of my day adding functionality to their core Validate class only to find that the functionality had already been added in a future revision. All I was looking to do was pass parameters to a custom callback function. I had even documented the entire change and was looking to post a feature request with an included patch. I later came to realize that the version I was using, 3.0.3, was outdated to the point of lacking this seemingly trivial functionality that was included in 3.0.7. So bare with me while I rant on why your framework is losing in the popularity contest.
A quick update.
I would like to preface this article by stating that the Kohana team has been making strides in their 3.0.x branch by including a Unit Testing Module which wraps PHPUnit, looking to eventually achieve 100% code coverage. In doing so, they have promised to no longer push changes in minor versions (3.0.x) which will affect the API in any shape or form. With that being said, there is still the possibility of them updating the core API to make improvements and additions to calls. Thanks to zombor for the clarification.
Please make your version changes more apparent.
The thought of you pushing or merging substantial feature changes into your latest branch and not referencing them in an organized and easy to follow manner on your website bothers me. You have absolutely no idea how many times I’ve had to dive into
modules/ to verify whether some feature is lacking or has been changed since a previous revision.
Redmine isn’t a substitute for posting feature updates.
I know you use Redmine diligently. I understand you’ve got your bug tracking on lock-down. This is no excuse, however, for providing lackluster documentation on recent changes to your core framework functionality in an easy to read manner. Your community is not solely comprised of your core development team. If I visit kohanaframework.org, I should be presented with the most recent core changes from version 3.x.x to 3.x.y and a link to past changes between revisions. The key word here is easy to read. I’m talking about an abridged version of updates to core files, including the basepath to the file in addition to the
class::method() affected. This is not only for the benefit of the community, but a benefit to yourselves as well. I gaurantee you’ll get less bug reports and feature requests if you keep your community well-informed. You can’t just assume that somebody wants to dumpster dive in the closed issues garbage. The subject lines of most of the bug/feature/patch requests are not generally descriptive enough to warrant a user actually clicking to read through them.
Kohana was intended for rapid development.
With rapid development comes the expectation that there is easily followable documentation and examples. I, as well as your community, know this to not be the case. I was actually in favor of your 2.x documentation. There are gaping holes in your new documentation and I’m forced to scour the API Browser which is simply auto-generated from your core class phpdocs. I’ve seen the section on What Is Kohana? titled This Documentation Sucks! I don’t believe linking to the external unofficial wiki is the proper solution. It’s a clear indication that you have a problem on your hands. I would gladly help work on updating your documentation upon request.
Et tu, Brute?
With that being said, I’m still an avid Kohana 3 user and advocate. Take this rant with a grain of salt and view it as a constructive criticism. I eagerly await the day you decide to take your framework more seriously as an alternative to some of the more widely advocated frameworks and bulster up the documentation and website. I believe these two key factors are what hinder you from more widespread support and praise. What you really need is someone within your team to take on the roles and responsibilities of managing your documentation.