NYCPHP Meetup

[Nate Abele]

> Date: Fri, 24 Jul 2009 11:46:32 -0500
> From: "Brian D." <brian at realm3.com>
> To: NYPHP Talk <talk at lists.nyphp.org>
> Subject: [nycphp-talk] Frameworks & Fast Iterations
>
> - How do you deal with quickly-morphing PHP frameworks when some
> applications tend to stay in production for years at a time?
> - Do any of you have a good experience with a framework that ages  
> well?

Hey Brian, interesting thoughts.  Certainly, this is something you  
deal with any time you're integrating 3rd-party libraries into your  
application, but especially so when dealing with a full-stack  
framework, since every part of the application is in question.  The  
idea that things change 'quickly' is somewhat curious though, since  
the speed of change is a relative metric.  Languages evolve very  
slowly, over a period of years, but technology, especially in our  
specific industry, can change almost monthly.  It seems appropriate  
then, that frameworks, which touch both ends of that spectrum, evolve  
at a rate somewhere between the two.

> As others have pointed out, the more abstracted a given foundation is,
> the faster it changes. C code pretty much works the same way it did 10
> years ago. PHP 5.3 is quite a bit different than the PHP3 code I wrote
> years ago. Frameworks (I've used Zend and CakePHP) change even faster
> - the code I wrote last year for Cake or Zend is quite a bit different
> than the code I write today.


I can only speak to the projects I've worked (i.e. CakePHP), but in my  
experience, the upgrade processes we've provided have, for most  
people, been fairly smooth.  So far in the history of the project, the  
biggest changes occurred between the 1.1 and 1.2 releases, where a  
significant portion of the helper API changed, many other methods were  
moved around, and a lot of new features were added.

While we didn't have the foresight at the time to develop a migration  
guide as we went along, but resources and tutorials quickly sprang up  
by people documenting their experiences with their own applications.   
Interestingly, one recurring item of feedback we received was that  
people spent the bulk of their migration time removing code that was  
no longer needed because of new framework features.  Spending  
migration time on removing maintainable SLOC seems like a fair trade,  
IMO.

As far as the changes to helpers, which were the most extensive, many  
of them were simply moved/renamed methods, with slightly modified  
parameters in some cases.  In the 7 releases and roughly two years  
between the 1.1 and 1.2 stable releases, we incrementally implemented  
these method changes by throwing deprecation warnings in the old  
methods for several release cycles before finally removing the old  
method.

Of course, the people who had the easiest time migrating were those  
with effective unit test coverage.  Between this and deprecation  
warnings, most migration issues between any CakePHP versions in the  
same branch should be immediately identifiable.

Given tests, and the ease with which you can move between CakePHP  
versions (i.e. usually just by replacing the "cake" directory), my  
suggestion on migrating across several releases would be to update to  
each release between your current one and the latest, one at a time.   
Run your tests, update your code, rinse and repeat.  Again, I can't  
speak for other frameworks or projects, but for CakePHP, this process  
is a lot simpler than you think.

Oh, also, we have a migration guide now: http://book.cakephp.org/view/411/Migrating-from-CakePHP-1-1-to-1-2 
  – and we'll have one for the upcoming 1.3 release as well (only a  
few very minor BC breaks in that one anyway, won't affect most apps at  
all).

- Nate Abele
   Lead Developer, CakePHP