Common libraries in a large team

Question

Assume you have five products, and all of them use one or more of the company\'s internal libraries, written by individual developers.

It sounds simple but in practice,

Answer 1

I would like to point a problem in the solutions suggested above: treating the library as an internal project with its own versioning scheme.

The problem

If your company has more than one product (lets say two teams - two product: A, B), than each product has its own release schedule. Let's give an example: Team A is working on product A v1.6. Their release schedule is two weeks from now (suppose Oct 30th). Team B is working on product B v2.4. Their release schedule is 1.5 months from now - Nov 30th. Lets assume both are working on acme-commons-1.2-SNAPSHOT. Both are adding changes to acme-commons, as they need it. Couple of days before Oct 30th, team B introduce a change which is buggy, to acme-commons-1.2-SNAPSHOT. Team A is getting into stress mode since they discover the bug 1 day prior to code freeze.

This scenario shows that treating a common library as a third party library is almost impossible. The trivial, but problematic, solution is for each team to have their own copy of the version they are about to change. For example, product A v1.2 will create a branch (and version) for acme-commons named "1.2-A-1.6". Team B will also create a branch in acme-commons called "1.2-B-2.4". Their development will never collide and they will be stress free once they tested their product.

Of course, someone will have to merge their changes back to the original branch (lets say master or 1.2).

The problems I found with this solution is:

1. Branch inflation - the tree structure will be very puffy and it will be harder to understand the flow of changes/merges.
2. Merges back to 1.2 will probably never happen - Unless a team/developer is dedicated to this library, the chances that Team A or Team B merges their code back to 1.2 branch is slim. They will always stay focused on their tasks, thus creating and using their own branch space. Allocation of a developer/team is expensive, thus not always a viable solution.

I'm still trying to figure this one out, so any thoughts of this matter are welcome