Date: Fri, 24 Jul 2009 11:46:32 -0500
From: "Brian D." <[email protected]>
To: NYPHP Talk <[email protected]>
Subject: [nyphp-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
_______________________________________________
New York PHP User Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyphp.org/show_participation.php
