Evitare conflitti di versione di dipendenza?

Qualsiasi progetto Java che utilizza il mio vaso, quasi sicuramente avrà un'ulteriore dipendenza da un altro vaso, che il mio vaso contiene anche come dipendenza.

Il problema è che l'altro vaso ha più versioni.

Come posso evitare eventuali problemi che potrebbero sorgere, nel caso probabile che la versione del secondo vaso del progetto sia diversa dalla versione del mio vaso del mio vaso?

Non voglio che i miei utenti abbiano il fastidio di fare qualche trucco di classe per aggiungere il mio vaso.

Dovrei solo creare un mucchio di versioni diverse del mio vaso, per ogni possibile versione di quella dipendenza comune? E poi scegli semplicemente la versione del mio vaso che usa la stessa qualunque versione del 2 ° vaso tu abbia già?

Esiste un modo più intelligente di gestirlo e rendere più facile per le persone usare il mio vaso senza conflitti?

Non è un tuo problema. Spetta all'utente finale risolvere. Viene solo con il territorio dell'utilizzo di dipendenze di terze parti e ho dovuto risolvere i conflitti di dipendenza più volte di quanto valessi. Non puoi aspettarti di soddisfare i conflitti di dipendenza specifici di ogni progetto.

Il software dovrebbe funzionare correttamente con le ultime versioni delle dipendenze. A meno che la dipendenza non cambi la loro interfaccia su ogni versione, è necessario disporre di una gamma di compatibilità (ad es. Il software funziona per tutte le versioni di dep in range [2.0.0, 3.0.0)). Finché stai mantenendo il software, dovresti provare a mantenerlo compatibile con l'ultima versione di tutte le tue dipendenze.

Detto questo, ecco alcune cose che troverei utili come sviluppatore usando il tuo software con la mia diversa versione della tua dipendenza.

• Se l'integrazione tra il tuo progetto e un altro progetto è limitata, è utile avere un diagramma di compatibilità nella documentazione. Indipendentemente da ciò, è necessario menzionare eventuali problemi noti con versioni specifiche della dipendenza nella documentazione. Altrimenti gli sviluppatori devono trovare una versione compatibile per tentativi ed errori.
• Astratta la collaborazione con la dipendenza tramite un'interfaccia e progetta il tuo software in modo che l'implementazione possa essere sostituita con l'iniezione della dipendenza. Ciò mi consente come utente finale di sostituire la mia integrazione con la versione x della libreria senza disturbarti.
• Disponi di un tracker di problemi pubblico in modo che i tuoi utenti possano chiederti di supportare determinate versioni della dipendenza comune. Se ritieni che molti utenti desiderino il supporto per una versione incompatibile della dipendenza, puoi pubblicare versioni per entrambi. Vedi questo esempio di Maven in cui hanno come target più piattaforme: il supporto per diverse versioni di una dipendenza dovrebbe essere simile.