I have been critical of ZF in the past because the performance has pretty much been going down every release and I am not the only one seeing this, there have been a number of benchmarks that show this trend.
Having contributed to ZF in the past I brought this issue up multiple times both on the mailing list and even during the meetings the past zendcons and it the general response was they where focusing on features not performance.
I have said it before, you can not give a blind eye to performance or you will go down a road that is hard to get back from.
During this years Zendcon they had another meet with the developers and 2 important things about the ZF where brought to light.
1. The next release will be a performance focused release.. This is good.
2. Once 5.3 is released and they feel adopted by enough of the community they will release 2.0.. This release will break BC in a number of areas mainly the MVC (arguably one of the most important aspects).
Why will 2.0 break BC? "We feel we need to refactor the MVC to improve performance and extendability, to this end we will also be moving up the min requirements to 5.3 so we can take advantage of all its new features"
So I have 2 simple questions...
1. If they had not focused so hard on pushing out features (which the MVC is packed full of) would they have to break BC today?
2. Is this a pattern for future "major" releases where they break BC to "fix" mistakes they made earlier?
*** Update/General comment 08/23/2008 ***
The point I am trying to get across is pretty simple, by not taking performance into concern from the very beginning it is very likely you will have to adjust in your future!
How many of these changes being discussed could have been avoided by not being driven by a pure "feature push" mentality and instead a true overall move forward.
Yes, this would of slowed development of ZF down a little but in return a more fine polished product would have been created that might not need "major revamping" at the 2.0 stage and instead they could be focusing on features now with less headache from the community about upgrade path.
Comments
The info is useful and interesting, rare combination
I'm not talking about Zend Framework, but about this article. Could you please avoid confusing "of" and "have"? It is quite disturbing.
Writing "Backward Compatibility" once before using "BC" might help to. I know your objective is performance, but don't forget to be user friendly ;)
Let me introduce myself; I'm Matthew Weier O'Phinney, software architect on the Zend Framework project.
The changes mentioned are not so much to "fix mistakes" as they are to take advantage of features that were simply unavailable prior to 5.3. With closures, late static binding, and namespaces, we can actually provide much better and simpler extensibility alongside better performance. A better way of putting it is that the language is finally catching up to our needs, and we want to write the features the way we intended them.
Additionally, as people adopt ZF, we're discovering and accomodating different use patterns. While we have strived to accomodate these, we're also getting to a point where we need to do a little re-architecting to make them fit within the MVC better.
Major revisions in many projects are reserved for exactly these types of changes -- architectural changes, or changes to accomodate the underlying language of implementation. If you look at PHP itself, PHP 6 is a backwards incompatible change made to accomodate unicode support in the language; PHP 5 introduced a new object model. Zend Framework is simply following this pattern so that we can better serve the users.
The changes in PHP 5 where not so dramatic, a majority of the scripts out there still ran.
The changes in PHP 6 mostly follow best practices and default settings and other then preg vs ereg and most people don't use ereg anyway since they are not binary safe. Again a majority of scripts out there at the time should still work.
The community argued greatly against changes that would risk a total breakage between even the major versions. Instead they did things to give the community time to adjust like turn features off by default even though a large part of the community thought the feature should of never existed to begin with (register_globals)
Will the ZF break BC every time a usefull new feature is released into php? Should people adopt ZF now knowing it will break with ZF 2.0/PHP 5.3.. What out PHP 6?
I think how ZF handles this "major upgrade" is going to set the tone for the future. If upgrading is a "tactical nightmare" you are quickly going to lose supporters no matter how useful the new features are.
We're not going to break BC just because we can; we're going to do it where it makes sense, and where we can benefit from new language features, plain and simple.
That said, something else we haven't made clear is that we fully intend to provide tooling to aid in upgrading. This may or may not be automated, but it's part of our roadmap.
I was at the "meet the team" session at ZendCon and have been using Zend Framework since before the 1.0 release. I would like to jump in with a few things I've observed along the way. First, it was mentioned during the session that the team will be working on getting a lot of features into the framework pre-2.0. This is so that they can see if any of these features needed to be refactored for the 2.0 release. The team has been very focused on backwards compatibility and there have been very few BC issues so far. So, the 1.7 release will certainly not be the last minor release in 1.x. Major releases are the time to refactor and break BC. It is unrealistic to expect complete BC in major releases. However, the team made it clear that even with the 2.0 release they are going to try to maintain BC as much as possible. Personally, I am perfectly happy with BC breaks in major releases as long as the previous major release is still maintained (security and bug fixes) for a reasonable period of time. It's simply the nature of our industry that progress sometimes requires a break with the past.
--
Bradley Holt
http://bradley-holt.blogspot.com/