First, SVN commits are *not* releases! They could only be considered daily builds at best.

The bigger picture I want to paint is that a lot of developers (both new and old) feel safe with official releases. There are so many bug fixes that should be released in subsequent *maintenance* releases. I don’t understand why they are all held for these minor releases ever X months. I stand by the creed to “Release early, release often”… and it’s something that I feel the cake devs don’t follow (with possible good reason).

I think it’s well known that the 1.2 branch is alpha but you sure don’t see anyone saying “Don’t use it! Use 1.x instead!”. It’s very confusing for newcomers to cake when they hear so much hype and stability of the 1.2 branch then are hit with the “sorry, its alpha” scapegoat of an excuse when something breaks/changes.

Also, as users of cake we shouldn’t have to police these commits. It seems it’s commonly left up to us to decide which commits are safe. I think with some *BASIC* keywords in commit messages could help a ton — but that’s just me :)

The trac timeline should be renamed to “activity log” :). It doesn’t really help at all when it comes to seeing when stuff WILL be completed or addressed. It’s reactive-based (meaning it only shows what has been done).

I am not trying to complain, I just see that addressing these issues would benefit the development process.

Let me show you a simple example of a test. Here the class we want to test:

class HelloWorld {
    function getHello() {
        return 'hello world';
    }
}

And here the test case where you define, what you expect the aforementioned class should do:

class HelloWorldTest extends CakeTestCase {
    function testGetHello() {
        $hello = new HelloWorld();
        $this->assertEqual('hello world', $hello->getHello());
    }
}

This test is then run via the test suite.

Is it now more clear?

@Proleter: What do you not understand?