E 'corretto mantenere i numeri di versione di tutti i componenti sempre gli stessi?

Question

E 'corretto mantenere i numeri di versione di tutti i componenti sempre gli stessi?

#1 da (8 voti)
#2 da (5 voti)
#3 da (3 voti)

6

Stiamo pianificando di utilizzare una configurazione che utilizza diversi moduli per completare un'intera applicazione, i moduli di esempio includono:

Il core (codice condiviso da tutti gli altri moduli)
Il server
Il client (Windows, OS X, Linux)
Il client (iOS)
Il client (Android)
Strumento n. 1
Strumento n. 2

E ora, mentre ci prepariamo a consegnare la nostra prima versione, è un buon momento per pensare allo schema di numerazione. Abbiamo definito l'utilizzo di un formato major.minor.patch, ma stiamo affrontando una sola domanda:

Se ogni modulo ha lo stesso numero di versione della versione più recente e, di conseguenza, dovremmo eseguire il bump dei numeri di versione se non ci sono stati aggiornamenti?

Esempio per illustrare:

1) Supponiamo che tutti i nostri componenti siano in esecuzione sulla versione 0.1.0 (sviluppo iniziale), una volta eseguito un aggiornamento significativo, allora tutti i componenti dovrebbero essere sottoposti alla versione 0.2.0?

Funziona anche al contrario:

2) Supponiamo che ogni componente sia inizialmente in esecuzione 0.1.0 e ora introduciamo un aggiornamento significativo (potrebbe essere una rielaborazione della GUI) sul client Android, dovremmo quindi rilasciare una versione 0.2.0 per ogni componente, anche se le altre versioni non hanno ricevuto alcun aggiornamento?

E forse la più difficile:

3) Supponiamo che eseguiamo ancora 0.1.0 uno molto componente all'inizio, e pensiamo che lo Strumento # 2 ha un bug e dobbiamo correggerlo a 0.1.1, dovremmo anche aggiornare ogni componente a 0.1 .1?

Attualmente dubito che dovremmo perseguire il corretto controllo delle versioni, o dovremmo optare per la compatibilità? Le persone esterne al team di sviluppo molto probabilmente si aspettano che tutti i moduli siano eseguiti sulla versione 0.3.0, ad esempio, mentre noi come sviluppatori siamo un po 'confusi e forse ci sentiamo a disagio con il bump di un numero di versione, mentre il modulo non ha modificato esso.

Qual è il modo migliore per affrontarlo?

Modifica , qualcosa che ho dimenticato di menzionare, ma che potrebbe cambiare opinione è che tutte le versioni verranno eseguite in modo automatico. Su Github / git un tag specifico verrà taggato come versione major.minor.patch e successivamente il sistema di compilazione (qui: Travis CI) prenderà il tag e creerà automaticamente ogni release e lo pubblicherà da qualche parte se necessario e / o voluto.

versioning

posta skiwi 08.09.2014 - 20:52

fonte

3 risposte

5

Dai un'occhiata a semver.org uno standard per il controllo delle versioni.

Traducendolo alla tua situazione, probabilmente significherebbe che le versioni principali non sarebbero compatibili tra loro, quindi un server 1.0 non può funzionare con i client 2.0. Le versioni secondarie sarebbero compatibili tra loro, quindi un server 1.2 può funzionare con un client 1.1 o 1.5, ma personalmente raccomanderei di rilasciare tutti i componenti quando si esegue il bump del numero di versione secondario. I bugfix / numeri di patch dovrebbero essere urtati quando è stato trovato un bug, ma non vorrei rilasciare tutti i componenti per questo.

Per quanto riguarda la tua domanda "è corretta", certo che lo è. In caso di versioning non c'è praticamente né giusto né sbagliato, la domanda che dovresti porci è: "questo schema di versioning è conveniente per noi (e ci costa un lavoro extra o ci risparmia lavoro) ed è chiaro all'utente? ".

risposta data 08.09.2014 - 21:13

fonte

3

No. Se non è stata apportata alcuna modifica a un modulo, non dovrebbe ottenere un nuovo numero di versione. Altrimenti stai seminando confusione e stai facendo più lavoro per chiunque stia facendo il tuo lavoro di rilascio. Trovo anche che sia più facile rintracciare i problemi quando puoi vedere quali moduli sono realmente cambiati rispetto a quelli che hanno semplicemente avuto il loro bump di gara.

risposta data 08.09.2014 - 21:28

fonte

Leggi altre domande sui tag versioning

Dovrei, e se sì, come faccio a imparare a favorire la progettazione in anticipo con l'astrazione sulla rimozione retrospettiva della ripetizione? [duplicare] Perché Scala indica la composizione monadica come "per la comprensione"?

score 8 · Accepted Answer

Prima di tutto, non c'è un modo corretto .

Tuttavia, ho riscontrato che mantenere tutti i numeri di versione uguali su tutte le versioni, indipendentemente dal fatto che le cose siano cambiate o meno, rende le cose molto più semplici lungo la strada. Se voglio sapere cosa sta succedendo in un software, tutto quello che voglio è poter passare facilmente da un numero di versione a uno stato nel controllo di versione e vedere cosa sta succedendo lì dentro. Avere una collezione di numeri di versione non correlati rende la cosa torbida.

L'alternativa è che alla fine devi mantenere una sorta di distinta base per le tue versioni del software per sapere cosa è cosa, e quelle invariabili non sono aggiornate o errate, e tutto diventa solo un gran casino.

Ci sono state situazioni su cui ho lavorato in cui i prodotti avevano una mancata corrispondenza tra i numeri di versione di varie DLL. Era un software per dispositivi medici e gli sviluppatori hanno razionalizzato il fatto che, non cambiando alcune parti, potevano evitare di fare test e verifiche per quelle parti. Potrebbe aver salvato il lavoro lì, ma ha creato un sacco di altri lavori e danneggiato la credibilità con i distributori anche quando la società non era sicura di cosa fosse per via dello schema di controllo delle versioni difficile da comprendere.