Il fatto che i progetti siano automaticamente "allineati" non ti dà vantaggi particolari. E neanche aggiornare un pacchetto NuGet solo perché c'è una nuova versione, che comunque è un'operazione che richiede tipo 10 secondi.
Se in una libreria condivisa è stato pubblicato un aggiornamento, spesso è necessario che anche i progetti che dipendono da essa debbano essere aggiornati per sfruttare quella funzionalità. E' questa la vera attività che richiede un discreto quantitativo di tempo, non il fare click per aggiornare un pacchetto.
Se tu "costringi" i progetti ad aggiornarsi all'ultima versione disponibile della libreria, puoi anche introdurre degli effetti indesiderati. Guarda come fa Microsoft con ASP.NET Core: anche se nella 2.2 ci sono dei miglioramenti prestazionali, bugfixing o dei cambi di comportamento migliorativi su alcuni piccoli aspetti del framework, lasciano libero lo sviluppatore di fare opt-in a queste migliorie come e quando desidera. E' per questo che quando registri MVC devi indicare la compatibility version:
public void ConfigureServices(IServiceCollection services)
{
services.AddMvc()
.SetCompatibilityVersion(CompatibilityVersion.Version_2_2);
}Siccome non sappiamo niente dei progetti di fractals87,
secondo me l'approccio più cauto è quello di suggerirgli una soluzione che gli permetta - se vuole - di gestire i cicli di vita dei due progetti in maniera indipendente. In questo modo potrà aggiornare il pacchetto in maniera esplicita, dopo aver letto le change notes che lui stesso ha scritto, così da essere perfettamente consapevole di cosa sta facendo.
Poi, siccome questa libreria ha anche un impatto sullo schema del database, starà alla sua perizia modificarla senza introdurre delle breaking change, altrimenti si spaccano i progetti sia che le modifiche siano veicolate col submodule GIT che col pacchetto NuGet.
ciao,
Moreno
Modificato da BrightSoul il 18 dicembre 2018 23.41 -
