We have accumulated a large codebase of somewhat-well-document projects, many of which aren't actively being used, but that we want to be able to start using again quickly if necessary.

What is the best way to automatically make sure that these projects stay in working condition as the dependencies backing different projects are upgraded?

These dependencies tend to be large, open-source and external, such as OpenCV and FFMPEG.

Between consecutive versions, they offer Warnings during compilation about the use of recently-deprecated functions; jump more than a few version, though, and updating becomes a significantly more challenging task.

  • I'm glad you moved this here from SO. Interesting question, this is a specific problem a lot of developers are facing and I would love to hear some common wisdom. Mar 19, 2013 at 21:48
  • The glib answer is "with a great deal of difficulty". We have a similar situation, and no real systematic solution other than doing the work to keep everything green across the board. Since this requires ongoing investment, you might also need to make the alternative (strategic) decision and remove components from active maintenance. Mar 20, 2013 at 12:22

1 Answer 1


There is an entire book dedicated to the concept of Continuous Delivery. (In fact, my Amazon search tells me that there are several. The idea is pretty simple. Create a test environment that closely matches your target deployment environment (using virtualization makes this a less daunting task). When you make a build, test the build within that environment. Once the build is validated, capture the configuration of that environment. Treat that deployment as a deliverable itself in other words.

If you have full control of where the application will be deployed, your job is done, promote the test environment to production and move on to the next phase.

If you are building an application for use by external users, it's a bit more difficult. In Linux, you can take advantage of apt and rpm to create packages that bring down the appropriate dependencies with them. So if your newest build relies on libGTK 4.6, (an example I'm not sure if there even is a libGTK 4.6) you can specify that within your package and you're golden.

On Windows, things get a little tricker. But the book I linked to also discusses options for addressing those scenarios.

  • While "Continuous Delivery" is an awesome book and this answer is pretty solid. I'd love to see it expanded a little. Specifically, I'd really enjoy some information about the challenges of depending on projects that are no longer being actively worked on, what are some good practices and rules of thumb when facing them, and perhaps some personal wisdom :) Mar 19, 2013 at 21:56
  • Whoa...so you want some from the trenches advice? That's definitely something I can provide. Just need some time to write it out. Mar 25, 2013 at 21:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.