You are mixing applications and librairies when they shouldn't.
A library has its own roadmap, which can be influenced by request of course, each time new features are released, the version change. However it has nothing to do with the application using it. When you upgrade the version of the library to have new features you have to test your application.
If you need to have a tool to manage your dependencies, they're tons of them : Maven, Gradle,... If for whatever reason you can't use one, take a look at how they work.
I think that your true concern may be more something along the lines :
I have to manage multiple application that share libraries, all of those are evolving, how do I ensure that I can safely continue to evolve everything and not lose control ?
I am probably not experienced enough, neither this post has enough character, for a long explanation so I will keep this very short :
- Versionning : a proper versionning is absolutely necessary with at least major/minor level. Eventually major/minor/bug fixes.
- Scope : each library/application must have a clear defined scope understood by everyone. So people know what they can expect from a library, and what just isn't there and won't because it's not in their scope.
- Backward compatibility : every libraries/Framework shared must ensure backward compatibility at their best. Don't remove code, use depecration. So people will see warning provding by the compilater that they use depracated methods, which may break on a next major release.
- Breaking change : if a breaking change in a library/framework is introduced because this is the way to go, it must be documented and usually part of a major version release. So you can continue to provides bug fixes, little functionnalities supports through minor version without having to introduces breaking changes.
- Documentation : everything part of a huge project must be documented (not necessary in a form of a very long and tedious text) : breaking changes, functionnalities (what ? from which version ?), bug fixes.
- Automatic non regression test : just THE way to go to ensure backward compatibility, each feature must have its regression tests and each bug fixed must have its own test (and eventually more than one).
- Diagrams : maintening a few diagrams showing the relations between components will save you the headache to do the same in douzenth of pages. You don't need to document each function call from which library for each applications, this is too much. Just that they have a dependancy and eventually a bit of context where is it used.
