Great post.

It’s important not to let talk of rapid releases detract from why this proposal exists. A framework has one very focused objective. It’s a stable platform over a period of time on which to build stuff. To assist in that objective we will very likely designate certain releases as LTS which can exist for many years benefiting from any security or high priority fixes necessary. Not only will this not result in the planet imploding, it will also ensure LTS versions are more stable than what ZF currently proves to be. Bug fixes of a non-essential nature, by their omission, will prevent any unintentional introduction of backwards incompatible changes and other inconsistencies where user workarounds and reliance on certain bugs are broken by such fixes. Fixing a bug, by its nature, is a changing of behaviour. LTS releases should prove exceptionally stable over time.

In return for having an LTS version with a greater degree of stability, non-LTS versions will follow an accelerated development process when it makes sense to do so. Obviously, we won’t start new major versions without a good reason to do so but we want to get ahead of the PHP version adoption curve where possible so that, when many PHP developers get around to adopting new versions, a solid Zend Framework version is already there waiting for them. This is a radical departure from how frameworks are currently developed at the tail end of PHP versions.

The accelerated model, once you recognise that LTS releases will occur, has a lot of merit. We can more rapidly integrate new thinking and learning, more rapidly respond to what PHP developers want and need and, critically, reduce the migration curve from version to version. We need to start favouring iterative improvements over complete rewrites. If following the curve does not appeal to all developers (and why should it?), the LTS releases will always be there a couple of steps behind offering the rock solid alternative, and where you want to mix LTS and edge components, well, the whole lot is versioned by component and packaged so you can mix up your preferred batch of goodies ;).

Paddy

Well said. Totally agree. It’s a good strategy for a smaller project. Might work for a mid-size project with an “agile angle” and a well managed team. Will mostly be a disaster for a large project.

Now from a different angle – frameworks are NOT applications, applications are NOT frameworks. Each new application I build is leaps and bound, lightyears ahead of previous one, as I always use all the newest tools, resources, knowledge and a sum of my experience (which makes me who I am).

From a maintenance perspective, when I have to fix, extend or just “adjust” older applications (which today seem like I carved them in stone with my teeth) I most certainly appreciate components (frameworks, libraries, tools) that have been updated and bug-fixed along the way, so I can just swap ver 1.01 with ver 1.31 and go to sleep being a happy camper.

Furthermore, I love it when I upgrade my PHP 5.0 to PHP 5.3, or MySQL 5.00 to 5.5, or newest jquery, just to find that my application not only is more secure, but also noticably faster, because there are some inside-changes that I don’t care how they work, but I love the result.

Emphasis put on the word “upgrade”.

Major vs minor is like evolution vs revolution. Most projects/apps that I’ve been part or has built, have had agile processes. This means that we innovate, iterate, learn and build huge things from sum of smaller parts. In start-up world that is a general expectation for most projects — 12mo for first GA beta is not enough any more. A workable prototype is expected in a month or two, otherwise it might be obsolete (or already done by someone else). But when it launches and stabilizes, more innovation comes in and “frozen”, working parts are expected to be stable and secure.

Framework is like a pillow, helpful when someone wants to kick you in the butt. Frameworks are not to innovate, but to give you a solid, dependable foundation you can build on. Putting any framework in an accelerated, bc-breaking life cycle will defeat that purpose.