Stai mescolando applicazioni e librairie quando non dovrebbero.
Una libreria ha una propria roadmap, che può essere influenzata dalla richiesta, ovviamente, ogni volta che vengono rilasciate nuove funzionalità, la versione cambia. Tuttavia non ha nulla a che fare con l'applicazione che lo utilizza. Quando aggiorni la versione della libreria per avere nuove funzionalità devi testare la tua applicazione.
Se hai bisogno di uno strumento per gestire le tue dipendenze, sono tantissime: Maven, Gradle, ... Se per qualsiasi motivo non puoi usarne uno, dai un'occhiata a come funzionano.
Penso che la tua vera preoccupazione potrebbe essere qualcosa di più:
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 ?
Probabilmente non sono abbastanza esperto, né questo post ha abbastanza carattere, per una lunga spiegazione quindi terrò questo molto breve:
- Versionning: una versione corretta è assolutamente necessaria con almeno il livello maggiore / minore. Eventualmente importanti / minori / correzioni di bug.
- Ambito: ogni libreria / applicazione deve avere un ambito definito chiaro e comprensibile a tutti. Quindi le persone sanno che cosa possono aspettarsi da una libreria, e ciò che semplicemente non c'è e non lo sarà perché non è nel loro ambito.
- Compatibilità con le versioni precedenti: ogni libreria / framework condiviso deve garantire la compatibilità con le versioni precedenti al loro meglio. Non rimuovere il codice, utilizzare depecration. Quindi le persone vedranno l'avvertimento che provano dal compilatore che usano metodi depracati, che potrebbero rompersi in una prossima major release.
- Rottura del cambiamento: se viene introdotta una modifica di rottura in una libreria / framework perché questa è la strada da percorrere, deve essere documentata e solitamente parte di una versione principale della versione. Quindi puoi continuare a fornire correzioni di bug, poche funzionalità supportano la versione minore senza dover introdurre modifiche irrisolte.
- Documentazione: tutto parte di un enorme progetto deve essere documentato (non necessario in una forma di un testo molto lungo e noioso): rottura di cambiamenti, funzionalità (cosa? da quale versione?), correzioni di bug.
- Test automatico di non regressione: solo la strada da percorrere per garantire la retrocompatibilità, ogni funzione deve avere i suoi test di regressione e ogni bug corretto deve avere il suo test (e eventualmente più di uno).
- Diagram: la manutenzione di alcuni diagrammi che mostrano le relazioni tra i componenti ti farà risparmiare il mal di testa per fare lo stesso in duecentocinquanta pagine. Non è necessario documentare ogni chiamata di funzione da quale libreria per ogni applicazione, questo è troppo. Solo che hanno una dipendenza e, infine, un po 'di contesto in cui viene utilizzato.