5

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.

Jay
  • 195
  • 2
  • 10
  • One company I was at ended up on an unsupported old version of Bugzilla for years, because of relatively minor changes which couldn't merge cleanly with upstream changes. Nobody ever had time to sort it out. Of course if we'd needed the upstream changes we'd have found time, but the moral of the story is that if you fork, then you will eventually hit a case which is *not* "easily upgradeable". Instead of trying to avoid that happening, aim to minimise the frequency at which it happens. – Steve Jessop Apr 04 '10 at 23:10
  • IMO this belongs on Programmars.SE, but since it's too old to allow migration, I'm just voting to close. – o11c Jun 29 '15 at 04:08

2 Answers2

6

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 Fetissov
  • 82,306
  • 11
  • 110
  • 171
  • +1 for wrapping - good idea to wrap all your dependencies yourself. – AshleysBrain Apr 04 '10 at 23:12
  • +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. Apr 05 '10 at 12:04
  • 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. Apr 05 '10 at 12:07
4

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
  • 11,763
  • 15
  • 70
  • 103