It may be a personal quirk of mine, but I like keeping code in living projects u

Question

It may be a personal quirk of mine, but I like keeping code in living projects up to date - including the libraries/frameworks that they use. Part of it is that I believe a web app is more secure if it is fully patched and up to date. Part of it is just a touch of obsessive compulsiveness on my part.

Over the past seven months, we have done a major rewrite of our software. We dropped the Xaraya framework, which was slow and essentially dead as a product, and converted to Cake PHP. (We chose Cake because it gave us the chance to do a very rapid rewrite of our software, and enough of a performance boost over Xaraya to make it worth our while.)

We implemented unit testing with SimpleTest, and followed all the file and database naming conventions, etc.

Cake is now being updated to 2.0. And, there doesn't seem to be a viable migration path for an upgrade. The naming conventions for files have radically changed, and they dropped SimpleTest in favor of PHPUnit.

This is pretty much going to force us to stay on the 1.3 branch because, unless there is some sort of conversion tool, it's not going to be possible to update Cake and then gradually improve our legacy code to reap the benefits of the new Cake framework. So, as usual, we are going to end up with an old framework in our Subversion repository and just patch it ourselves as needed.

And this is what gets me every time. So many open source products don't make it easy enough to keep projects based on them up to date. When the devs start playing with a new shiny toy, a few critical patches will be done to older branches, but most of their focus is going to be on the new code base.

How do you deal with radical changes in the open source projects that you use? And, if you are developing an open source product, do you keep upgrade paths in mind when you develop new versions?

Explanation / Answer

The issue isn't unique to open source. The same issues occur with commercial projects. Maybe even more so because you don't have source you can maintain yourself if the company drops support.

End user type open source projects have rapid upgrade cycles and old versions lose support very quickly. On the other hand, projects that are designed for users to put significant effort coding on top of tend to have long support cycles of the old branch after a major upgrade. Long enough for you to take your time first waiting for it to stabilize and mature, then migrating and thoroughly testing your own code.

It can be difficult resisting the temptation to have the latest and greatest, but realize there is a fundamental tradeoff in software between stability and new features. You can't have one without sacrificing the other. That's why bugfix branches exist, so you can choose what side of the spectrum best fits your needs.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.