How should common interfaces be shared across source control repositories?

Question

I have code that represents the interface for a library that is used by a variety of internal clients. How should that interface code be exposed to these internal clients that live in different source control repositories?

The interface should be relatively stable, but is in development (as is most of the internal clients) so keeping changes communicated is important, as is keeping breaking changes to a minimum. Normally, I would just directly reference them in the other modules but the separated nature makes that troublesome.

• Lie Ryan: Git allow a folder to be managed by a different, independent instance of git, using git submodule. You might be looking for something similar in your version control.

Answer 1

There are multiple ways and it really depends on your library/setup.

Typically you can reference other repositories, e.g. with submodules for git or for example externals and svn. This is the simplest and probably also hackiest solution as you are directly referencing to the library and your clients would have to build them as well.

You can provide binary packages for your library, e.g. gems/eggs/debs/rpms/... and just reference it from your build process or assume it is present at runtime. This is in my opinion a quite clean approach.

Let your buildsystem handle the dependencies, e.g. rely on maven or use other tools like bundler/carton/openembedded or other similar tools for your language. They can automatically download and build your dependencies.