Numero di versione per più software provenienti dalla stessa base di codice

Question

Numero di versione per più software provenienti dalla stessa base di codice

#1 da (5 voti)

2

Al momento disponiamo di una grande base di codice da cui possiamo generare 5 software differenti. Il codice base è composto da circa 20 sottomoduli che sono utilizzati (o meno) da ciascun software.

Mantenere un semesto per ogni software porterà probabilmente a un incubo. Finiremo con una tonnellata di tag e rami sul nostro repository git.

Sto pensando di dare un numero di versione al codice base e ogni volta che viene rilasciato un software, esso eredita questo numero. Tuttavia, vedo un grosso inconveniente con questo metodo:
Diciamo che sono alla versione 1.0.0 e rilasciando tutto il mio software, quindi sono tutti nella versione 1.0.0.
In seguito, rilascerò una grande funzionalità nella base di codice che ora è nella versione 1.1.0.
= > I software 1,2 e 3 usano questa funzione e sono rilasciati nella versione 1.1.0.
= > I software 4 e 5 sono ancora 1.0.0.

Ora, ho bisogno di correggere un piccolo bug nella base di codice per tutti i software. La versione di base del codice è ora 1.1.1. Rilascio tutti i software:
= > I software da 1 a 5 sono in 1.1.1.
Quello in cui non sono così sicuro di questo metodo perché il Software 4 passa dalla 1.0.0 alla 1.1.1 solo per una soluzione minore.

Sto anche pensando di avere un semere per il codice base e un numero più user friendly per ogni software che nasconderà il salto imbarazzante nel numero di versione:

-------------------------------------------------------  
| codebase  | Software 1  | Software 2  | Software 2  |  
-------------------------------------------------------  
| 1.0.0     |    2018.1   |    2018.1   |   2018.1    |  
| 1.1.0     |    2018.2   |    -        |     -       |  
| 1.1.1     |    2018.3   |    -        |   2018.2    |

C'è un modo più semplice di gestirlo?

versioning semantic-versioning

posta grunk 13.07.2018 - 14:50

fonte

1 risposta

Leggi altre domande sui tag versioning semantic-versioning

Per utilizzare una sola volta il pulsante di richiamata, il nome dovrebbe essere più correlato al pulsante o all'attività del callback? Come selezionare ogni x% di record per l'elaborazione

score 5 · Accepted Answer

Hai elencato 2 ampie aree problematiche. 1) Controllo delle versioni del repository. 2) (non tanto di problema) traduzione di numeri di versione che a volte è utile per utenti non esperti.

Il primo problema può essere notevolmente semplificato eseguendo il refactoring del codebase composto da git submodules in repository git separati.

Potresti chiamarli librerie, ma sono progetti individuali che hanno un proprio ciclo di vita. Questo perché un modulo utente, che ora è un repository, necessita di modifiche, bene questo è il ciclo di vita del modulo utente in modo che possa essere taggato e seguire il controllo delle versioni semantico.

I singoli software potrebbero avere un po 'di codice, ma almeno hanno sistemi di compilazione e la maggior parte di questi progetti effettivamente realizzano un rilascio e una distribuzione per gli utenti finali (sto assumendo ora). Quindi questi software 1, 2, 3 .. ciascuno dovrebbe anche essere un repository separato e il proprio versioning. Una bella distinzione che voglio aggiungere qui riguarda la distribuzione. Se uno stesso "software 1" produce diverse distribuzioni, ad esempio iOS, le distribuzioni Android dalla stessa base di codice non dovrebbero creare un repository separato per questo. In altre parole, non chiamare il software 1 come iOS e il software 2 come Android se la logica aziendale e le funzionalità provengono dalla stessa base di codice ed è proprio come la si impacchetta.

Detto questo è necessario stabilire confini chiari tra i repository. Questo può essere fatto usando le interfacce di definizione e assicurandosi che questi progetti condividano gli artefatti QAed completati.

A volte gli sviluppatori tendono ad aggiungere più progetti in un singolo repository (e quindi usano i moduli git) per portare ciascuno di loro nel loro IDE preferito che sembra conveniente al momento, ma dà origine al problema che si sta affrontando.

Per affrontare l'affaticamento della separazione è possibile utilizzare una buona pipeline CI / CD e automatizzarli. La tua distribuzione di librerie può produrre mappe di origine o la capacità di collegare fonti al codice compilato che è condiviso in modo da poter sviluppare "software 1" (lo chiamiamo "Applicazione" BTW).

Ma se il repository separato causa più lavoro rispetto alla confusione che hai identificato, assumi quella complessità della versione. Ricorda che i benefici di progetti gestibili più piccoli sono troppi per elencarli qui rispetto a un grande progetto monolitico. Potresti cadere o iniziare a ripensare perché hai i sottomoduli in primo luogo. Come ti rendi conto dell'analisi dei benefici.

Il secondo problema è rappresentato dalla trasformazione della versione. 1.0.0 a 2018.1. potresti scrivere una piccola funzione deterministica e usarla ovunque.

Il post lungo ma il controllo delle versioni semantico è solo più di un numero.