How to organize repositories for a split library?

Question

I have two libraries that implement a protocol: one provides tools for establishing a channel between two parts, and the other provides classes and tools for building and parsing the binary protocol messages.

These two libraries can be used independently, they don't depend on each other, and each has its own build setup. However, they do share a common set of examples (using both libraries) and documentation (tutorials).

---

I have two alternatives in mind for organizing this in Git repositories:

Alternative 1

Make each library be in its own repository. A central repository would keep the common documentation, examples and tools for cloning both repositories and bootstraping them. Users would use this main repository, and developers would work on the dedicated repositories.

I don't want to use Git submodules since they are hard to manage this way (versioning becomes much harder to do when the libraries constantly change).

Alternative 2

Place it all together: both libraries, documentation and examples. Versioning would be applied to both libraries, since they would be treated as a single (though separated) entity.

This is how we are doing it now. It makes things simpler but I feel it could be improved.

---

So... what are the best practices for organizing it all using Git? I'm open to other alternatives too.

Even though we're not using it right now, it's possible that we will be using continuous integration tools, automated testing and builds, etc.

Answer 1

Source code repositories (i.e. git or other vcs) should be organised for the convenience of those who work on the source code; fix, extend and release it.

Binary repositories (i.e. Debian, maven-based repositories, etc.) should be organised for the convenience of those who work with the libraries.

Sometimes, in the short term, you use the source code repository to deliver stuff to your end-users, just because anything else would be overkill. In that case, then by definition it's not worth reorganising things for their convenience; what you are doing is either too simple, or has too few end-users. If that changes, then set up a binary repository rather than reorganise.

As you say you want to version the two things together, that suggests a single repository. And it doesn't sound so big that you are hitting the point you want to split the repository for performance reasons.