Versioning and release management with multiple products with shared code base

Question

I am currently trying to figure out, how to do release management with git flow in a scenario where I have one git repository with about 15 projects in two solutions plus scripts for the database.

Each solution basically contains one project that will result in an executable and more than 10 projects containing base functionality used by both solutions like DAL, SAP access wrapper etc.
Solution one is an application with UI for the users.
Solution two is a Windows service.
The release of the two solutions and the database are not in sync. This means that frequently only one ore two of the three are being released. This results in different version numbers. For example, the UI is released quite frequently, the service is released seldomly. The database somewhere in between. So, the UI could have version 2.1.15, the service 2.1.1 and the database 2.1.5.

Now, what to do with the shared projects? Should they use the version number of the UI or that of the service?
How would I account for the fact that a change in one of the shared projects wouldn't automatically trigger a release of both solutions? This means that at the same time, the production environment contains two different versions of the same projects. This somehow needs to be reflected in the repository.

I am a little bit lost here, any advice, experience etc. would be appreciated.
I am free to structure the repository and code base in any way and I can create additional repositories if that helps.

Answer 1

First off, if you have different (even though somewhat dependent) projects, that are different enough for them to have different versions, then by all means put them in different git repositories.

If you have all your products under the same repository you are just being inefficient. For example, if you are working on the UI and another is working on the service and made a small fix to the UI, then when you merge your work with them, you get their change of the service too (which you didn't care for).

From your 15 projects, if some are too tightly related, you could keep them in the same repository (for example the components of the UI).

Now that you have different repositories, you can easily manage separate releases for them and separate version numbers.

One thing you want to be careful with though, is compatibility. For example, your UI with version 2.4.5 may be compatible with the service with version in the range 2.1.7-2.2.9, and likewise, the service with version 2.1.10 may be compatible with UI with version in the range 2.4.3-2.4.8. Each version of your software components should then be able to check the version of the other components for compatibility.