Lavoro in un'azienda che si occupa di software specificamente progettato per clienti di terze parti in uno schema Business-To-Business. Disponiamo di varianti di un software di grandi dimensioni, che per ogni cliente viene specializzato e alla fine ci ritroviamo con diverse edizioni dello stesso programma padre.
Poiché ci occupiamo attivamente di dispositivi fisici, ogni "edizione" è composta da componenti separati che, in un modo o nell'altro, parlano a ciascun dispositivo, in modo univoco. Nel modulo corrente, ogni volta che aggiungiamo una nuova funzione a un componente o correggi un bug in alcuni di essi, rilasciamo una versione più recente del intero programma (a causa di evidenti limiti tecnici nella separazione dei componenti e rilasciando singoli aggiornamenti con loro), che contiene la versione corrente più il nuovo componente.
Per semplificare le cose, dividiamo il programma:
- Sezione UI, ovvero versione
2.0.0.1. - Componente A, ovvero versione
1.0.2.7. - Componente B, che è la versione
1.0.3.9. - Componente C, che è la versione
1.0.0.1.
Poiché le nostre modifiche riguardano principalmente la sezione dell'interfaccia utente, è più comune che l'intera applicazione utilizzi la versione del componente dell'interfaccia utente; quindi nel nostro esempio è la versione 2.0.0.1 . Se apporto una modifica al componente A, eseguo il bump della sua versione su 1.0.2.8 (diciamo che si tratta di una piccola correzione di bug), contrassegno l'intera soluzione e quindi la mia applicazione sarà la versione 2.0.0.2 .
Considera anche che non stiamo scambiando componenti separati con altri team che lavorano a "edizioni" diverse dell'applicazione madre e che il cliente alla fine un singolo eseguibile della sua versione personalizzata ( 2.0.0.2 ), indipendentemente dalle modifiche che ho inserito all'interno.
La mia domanda è questa: poiché l'applicazione è sempre considerata one and whole , c'è qualche ragione per tenere traccia dei diversi numeri di versione di ciascun componente? Sicuramente, questo aiuterà gli sviluppatori a sapere internamente come è vecchio o nuovo un componente (poiché tutto parte da 1.0.0.1 ), relativamente ad altre parti dell'applicazione, ma questo può anche essere conosciuto sfogliando il repository all'interno del codice sorgente di un componente. Ci sono altri argomenti per questa strategia?
Nota a margine
Perché forse non è diventato evidente dalla domanda precedente: i componenti sono not scambiabili. Non sono stati trovati in nessun'altra "edizione" dell'applicazione madre, tranne quella inizialmente progettata per. Quindi non ci sarà un cliente Z in futuro, ruggendo sul motivo per cui abbiamo messo alla sua versione del componente A versione 3.0.0.1 come la sua variante supporta fino alla versione 1.5.0.1 . Ovviamente c'è un insieme di componenti comuni, ma non sto parlando di loro. Questi sono mantenuti in un albero / progetto sorgente completamente diverso, da un gruppo completamente diverso. La mia domanda è rilevante solo per i blocchi di una "edizione" che costituiscono i suoi componenti unici.
Nota a margine 2
So che cambiare pochi KB di codice nel componente A e quindi preparare un intero nuovo rilascio che pesi alcune centinaia di MB perché non si utilizzano versioni delta, è per lo meno zoppo. Se i componenti fossero rilasciati separatamente, il controllo delle versioni sarebbe perfettamente logico. Ma la mia azienda non è l'unica che va con rilasci grassi e, anche se non apprezzo questa tecnica, riesco a capire le ragioni per cui alcuni anni fa li hanno scelti rispetto all'altro.
Quello che sto cercando di identificare è se c'è un altro motivo significativo ma altrimenti nascosto per continuare a etichettarli, con loro che sono indivisibili dall'app principale.