Quando un commit non dovrebbe essere taggato con la versione?

30

Contesto: recentemente ho scoperto Semantic Versioning e sto cercando di determinare come utilizzarlo al meglio praticamente per i miei progetti.

Dato che semver tiene conto delle modifiche importanti, delle modifiche minori e delle patch per il controllo delle versioni, quando un commit non dovrebbe essere taggato con una versione aggiornata? Mi sembra che ogni cambiamento si inserisca in una di queste categorie, e quindi ogni cambiamento dovrebbe essere aggiornato, ma quando guardo vari progetti popolari su GitHub questo non sembra essere il modo in cui le cose vengono fatte (solo guardando fatto che i grandi progetti hanno decine di migliaia di commit, con solo centinaia di tag).

— VortixDev
fonte

23

È ogni impegnano a padroneggiare una stabile, testato, la qualità garantita rilascio nel vostro progetto?

— Alex Reinking il

1

@AlexReinking Ogni commit viene testato, ma sto solo cercando di abituarmi a pratiche comuni con i miei progetti personali, quindi sono solo io a lavorarci e come tale non esiste davvero un sistema diverso da "fare un cambiamento, testare me stesso, commettilo ".

— VortixDev

Si noti inoltre che i tag possono essere modificati in un secondo momento. L'unico identificativo di commit solido è la chiave hash di commit.

— Thorbjørn Ravn Andersen,

9

ogni impegno da padroneggiare ??? non dovresti mai impegnarti a padroneggiare. Ogni unione da padrone suona molto meglio.

— xyious

2

Penso che @xyious colpisca l'unghia sulla testa. Ogni commit che finisce sul master dovrebbe essere taggato con una versione perché ogni commit sul master dovrebbe essere una fusione di rilascio dallo sviluppo .

— BJ Myers,

71

SemVer preoccupazioni delle versioni release , non commette . Se il modello di controllo della versione richiede che ogni commit da master sia una release, allora sì, ogni commit dovrà essere taggato in base al grado della modifica.

In generale, tuttavia, i progetti sviluppano un prodotto per lo più stabile sul master e contrassegnano le versioni che ritengono meritevoli di supporto. Quando lo fanno, taggeranno secondo il loro schema di versioning, che non deve essere necessariamente SemVer in particolare.

— Alex Reinking
fonte

5

SemVer ha senso soprattutto per le librerie in cui l'utente è altri bit di codice e non umani. Non ci sono davvero "interruzioni" delle modifiche nella maggior parte delle app rivolte agli utenti perché l'utente può adattarsi automaticamente alla nuova versione.

— Qwertie

5

Direi che le versioni da riga di comando delle app rivolte agli utenti dovrebbero essere semanticamente controllate dal momento che i loro flag e formati di output possono comportarsi diversamente. Un po 'di un'area grigia.

— Alex Reinking il

5

@Qwertie Le aspettative degli utenti sono meno rigide delle aspettative del software, ma esistono ancora. Ho DEFINITAMENTE usato molti software che hanno emesso modifiche che riterrei "rompere" la loro interfaccia o funzionalità. Decidere cosa costituisce una versione maggiore o minore è certamente più soggettivo che con le biblioteche, ma non è necessariamente un motivo per evitarlo.

— Iron Gremlin

11

@Qwertie: trattenere l'aggiornamento. Quante persone eseguono ancora vecchie versioni principali di Windows e Office?

— Alex Reinking il

5

@Qwertie Potrebbero essere ispirati a leggere attentamente il registro delle modifiche o la documentazione in modo da poter adattare il modo in cui usano il sistema per utilizzare funzionalità nuove o modificate o trovare soluzioni alternative per una funzionalità che è stata rimossa. È lo stesso caso, il loro uso del software deve cambiare perché il software è cambiato, quindi dovresti dire loro di quel cambiamento senza ambiguità.

— Iron Gremlin

11

I numeri di versione sono assegnati alle versioni. In generale, non tutti i commit dovrebbero essere una liberatoria. Ci sono diverse ragioni per questo.

In primo luogo mentre dici di "testare" ogni commit ci sono livelli di test. L'esecuzione di una suite di test automatizzata su una sola macchina va bene, ma in un software complesso probabilmente non affronterà ogni problema. Alcuni problemi potrebbero essere specifici dell'hardware o della configurazione, altri potrebbero riguardare più le considerazioni umano-soggettive che quelle relative a requisiti testabili.

In secondo luogo, superare il numero della versione principale dovrebbe essere un'azione rara. Fondamentalmente significa che tutto ciò che dipende dal tuo software deve essere controllato manualmente per vedere se dipende da una qualsiasi delle funzionalità rimosse.

Una conseguenza di ciò è che dovresti aggiungere funzionalità alla tua "API pubblica" solo nelle versioni complete (non alfa / beta) se sei pronto a supportare quelle funzionalità nella loro forma attuale a lungo termine.

In terzo luogo, è utile ridurre il numero di versioni in uso diffuso. Anche su un ramo stabile è spesso meglio riunire un numero di correzioni insieme e creare una singola versione piuttosto che rilasciare una versione per ogni correzione.

— Peter Green
fonte

2

Sembra ovvio dirlo, ma: uno scopo dei numeri di versione è quello di consentire di determinare facilmente quale versione del software è in esecuzione.

Se esiste la possibilità che qualcuno abbia accesso a una particolare iterazione del codice e non sia altrimenti in grado di determinare facilmente un identificatore univoco, tale iterazione dovrebbe avere un numero di versione univoco. Vedo questa come la "prima regola". Di conseguenza, versioni distinte richiederanno chiaramente numeri di versione distinti.

Tuttavia, ne entra in gioco di più:

Un modo per essere sicuri di questo è aumentare i numeri di versione con ogni commit, ma di solito non è una buona idea. Potrebbero essere necessari diversi commit / iterazioni per far funzionare un cambiamento relativamente piccolo, ed è confuso per il mondo esterno vedere la versione 0.0.1 -> 0.0.2 come risultato di un gran numero di modifiche accumulate quindi 0.0.2 -> 0.0 .56 perché qualcuno ha commesso uno spazio bianco corregge un file alla volta e non ha cambiato nulla di funzionale.

Quanto lontano da "una versione per versione completa" a "una versione per ogni commit" dipende davvero: tu, gli altri utenti e quali sistemi sei disposto a utilizzare per colmare le lacune.

Personalmente sono abituato a lavorare su piccoli progetti e sono felice di usare gli hash git fino a una versione che altri usano e una versione bump per ognuno di questi (non importa quante persone mi aspetto di metterlo per mano). Tuttavia, nelle aziende più grandi e nei progetti più grandi, viene utilizzato qualcosa al di fuori dei numeri di versione semantica, ma viene utilizzata una fedeltà inferiore rispetto a ciascun commit, come la numerazione dei candidati al rilascio. Questi hanno vantaggi ma aggiungono complessità.

— Anone
fonte

0

Ogni richiesta pull che viene unita al master deve essere versionata.

Se non dovrebbe essere una nuova versione (almeno una patch), probabilmente non dovrebbe essere unita a master perché la funzione / correzione / etc non è completa.

Tuttavia, a seconda del flusso di lavoro del tuo team, potresti comunque finire con più commit da padroneggiare senza una versione. Se ci sono diversi commit in una richiesta pull che non vengono schiacciati (secondo me non dovrebbero), potresti comunque finire con 10 commit e solo 1 nuova versione.

— xyious
fonte