Well, that's why I stated it the way I did. Making some minor API changes between 1.0 and 2.0 is expected, but if a developer has to learn a completely new API and change every line of his code that uses ZF, that would not be good.
Another form of preserving backward-compatibility is to create implement new classes and methods that coexist with old ones, without affecting apps that use the old code. That's why you see methods like mysqli_real_escape_string() or execute2(). I really dislike seeing things like that, but they are sometimes necessary to preserve backward compatibility. So, in short -- yes, seriously, backward-compatibility is important. Zend Framework will achieve more success and more IT departments will use it, if and only if the project shows some commitment to keeping API contracts. Regards, Bill Karwin > -----Original Message----- > From: SantosJ [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 13, 2007 8:12 PM > To: Bill Karwin > Subject: Re: [fw-general] Zend Framework 0.9 beta feature-freeze > > Oops, that was a lot of stuff and I didn't read it all. I don't like > this part, "...an application using Zend Framework 1.0 does not have to > be totally rewritten to use Zend Framework 2.0." > > Seriously? I think it might be a good idea to allow such a refresh so that > refactoring can occur at the major release level. I don't think many would > mind updating for a major (2.0, 3.0, etc) release, but would on a minor > (1.1, 1.2, 2.1, etc). At least I don't mind or won't mind whenever the > case might be. > > Jacob Santos > > > But even in the trunk, we will emphasize backward-compatibility wherever > > possible, so that when we release Zend Framework 1.1, 1.2, 1.3, and > > other future enhancements, users of Zend Framework will have an easy > > transition and can adopt new features. One of the quality goals of this > > project is that an application using Zend Framework 1.0 does not have to > > be totally rewritten to use Zend Framework 2.0. After 1.0, any change > > to the API must be approved by a Change Control process, and accompanied > > with detailed documentation to describe how to migrate an existing > > application to the new API change. > >
