NYCPHP Meetup

NYPHP.org

[nycphp-talk] Frameworks & Fast Iterations

Chris Snyder chsnyder at gmail.com
Sat Jul 25 16:20:48 EDT 2009


On Sat, Jul 25, 2009 at 1:10 PM, Leam Hall<leam at reuel.net> wrote:
> If you're coming out with site-breaking changes every 6 months and not
> supporting older versions, why would anyone use the product? Frameworks
> should be a tool, not a master. They should save time.
>
> Or so I thought. Saves me the trouble of learning one.
>
> Leam

Oh no, that's exactly right. But at the same time, if you don't
release a new version of your framework every six months developers
get antsy about whether the project is abandoned. Can't win.

This is a pretty run-of-the-mill problem in programming. When you
write code, you depend on the behavior and quirks of whatever
languages and libraries you are developing against. If you made good
(or lucky!) decisions about what to depend on, the languages and
libraries will evolve without breaking your code. If not, you'll spend
time refactoring after an upgrade.

Frameworks, especially stable, well-documented frameworks, save time.
Unquestionably. And when new versions break compatibility, at least
you're not alone in having to find workarounds.

Some tips, I guess:

Don't customize the framework. As changes you make to framework code
will likely need to be made each time you upgrade the framework, and
may break other things over time. Write compatibility functions or
override methods or something instead.

Don't be afraid to upgrade. The sooner you get it over with, the less
pain you'll face on the next release. Release notes for version n.0 of
a product will often include detailed lists of gotchas and ways in
which compatibility is broken. Notes for version n.1 and beyond will
not.

Lurk on developer mailing lists or blog so that you know about big
changes in advance.

Branch your project so that you can work on supporting next release of
the framework even as you support previous release in production.

Finally, maybe this is too obvious, but I use symbolic links to point
to specific versions of third-party packages:

somelib-2.1.3
somelib-3.0.1
somelib -> somelib-2.1.3

When the time comes to upgrade, you just remove the link and relink to
the newer version. This makes it easy to roll back quickly if
necessary.



More information about the talk mailing list