views:

194

answers:

2

Our team is moving into much larger projects in size, many of which use several open source projects within them.

Any advice or best practices to keep libraries and dependancies relatively modular and easily upgradable when new releases for them are out?

To put it another way, lets say you make a program that is a fork of an open source project. As both projects grow, what is the easiest way to maintain and share updates to the core?

Advice regarding what I'm asking only please...I don't need "well you should do this instead" or "why are you"..thanks.

+5  A: 

With clones of open source projects one of your biggest headaches will be keeping in sync/patched according to the upstream sources. You might not care about new features, but you will sure need critical bug fixes applied.

My suggestion would be to carefully wrap such inner projects into shared libraries, so you can more or less painlessly upgrade just those parts if the ABI is not broken by the changes.

One more thing - if you find and fix bugs in an open source project - don't keep the fixes to yourself. Push the patches upstream. That will make the project better and will save you days of merging with a new version.

Nikolai N Fetissov
+1 for wrapping - good idea to wrap all your dependencies yourself.
AshleysBrain
Great advice! Thanks!
Jay
+1 for suggesting to push back the patches: even if you don't feel like sharing, think you'll get community support on your own patches afterward, so there's really no reason not to.
Matthieu M.
I would also say +1 for wrapping... but I can't upvote twice. Anyway wrapping 3rd party software is a no-brainer (at least for classic code, pure template code is more difficult). Wrapping allows you to adapt to interface changes in one place and not let it ripples throughout the company code repository. Finally, like all middleware activity, you better make sure you get some good dev to work on it, since it'll be use extensively, you don't want it to be buggy.
Matthieu M.
+3  A: 

In order of preference

  1. Make as few changes as possible to the third party libraries. Try and get around their limitations within your code. Document your changes and then submit a patch.
  2. If you can't get around their limitations, submit your change as a patch (this may be idealistic with the glacial pace of some projects).
  3. If you can't do either of those things, document what you've changed in a centralized location so that the poor person doing the integration for new versions can figure out what the heck you were doing, and if the changes made are still needed.

1 and 2 are greatly preferred (however, fast and very slow respectively), while the third option will only lead to headaches and bugs as your code base deviates from the dependencies' code base. In my code, I don't even have the 3rd party code loaded up in the IDE unless I have to peruse a header file. This removes temptation to change things that aren't mine.

As far as modularity, and this is assuming you are using relatively stable 3rd party libraries, only program to the public facing interface. Just because you have the source doesn't mean you have to use it all over your code. This should allow updates to be essentially drag and drop. Now, this is completely idealistic but its what I strive for with code I work on.

Steve
Thanks for your advice!
Jay