Git, versioning semantico e come si adatta (mio) a una tipica timeline di sviluppo?

Hai detto che stai utilizzando il controllo delle versioni semantico, quindi ti consigliamo di guardare le specifiche di versione semantica su link :

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible manner, and
3. PATCH version when you make backwards-compatible bug fixes.

Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

e un po 'più in basso:

A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

Quindi se rilasci una beta vera della tua versione 1.0, dovresti taggarla 1.0.0-beta (o simile secondo le specifiche). Se stai per avere più versioni beta mentre correggi bug, allora 1.0.0-beta.1 , 1.0.0-beta.2 , ecc.

Quando si aggiungono funzionalità compatibili con le versioni precedenti, è necessario incrementare il numero MINORE. Se si apportano molte modifiche interne che potrebbero causare cambiamenti irreversibili altrove nell'applicazione, allora si tratta di una modifica MAJOR. Se stai apportando modifiche meno evidenti (ad esempio, solo il aggiungi codice e non cambia il comportamento del codice esistente), allora questa sarebbe una modifica MINORE. Se hai un'applicazione pesante per l'interfaccia utente e cambi completamente quell'interfaccia utente, direi anche che è una modifica MAJOR (l'interfaccia utente può essere considerata l'API per gli utenti finali).

Per quanto riguarda come aggiungere indicatori al repository git, ti suggerisco di creare prima un ramo 1.x . Ciò ti consentirà di seguire facilmente tutto nella versione 1, consentendo al contempo lo sviluppo continuo della versione 2 su master. Quindi tagghi la versione beta con un tag 1.0.0-beta (o -beta.1 se ci saranno più beta). Una volta risolti tutti i bug da correggere, tagga la versione 1.0.0 effettiva. Quindi tagga ogni versione se necessario.

Puoi dare un'occhiata ad alcuni workflow provati e veri per git come git flow e flusso github per idee su come impostare il flusso di lavoro in corso.

Inoltre, se vuoi un po 'più di contesto sulla versione semantica dei programmi senza un'API, questa risposta va in una certa profondità.

Sì, aggiorna il numero di versione ogni volta che esce dal tuo controllo e in quello di qualcun altro.

il motivo è che hai bisogno di sapere con cosa stavano lavorando. Quando il test ritorna e dice "abbiamo trovato un bug nella versione 1.0.0", l'ultima cosa che vuoi dire è "quale versione 1.0.0, quella che ti abbiamo dato lunedì o quella che ti ho dato venerdì? "

L'aggiornamento del terzo numero è davvero progettato per questo, la differenza funzionale tra 1.0.0 e 1.0.999 dovrebbe essere limitata, quando si aggiungono grandi nuove funzionalità, quindi si aggiorna il 2 ° numero. Tuttavia, l'aggiunta di un nuovo campo di input di ricerca non conta come una modifica abbastanza grande da giustificare un secondo aggiornamento del numero, ma YMMV.

Personalmente, tendo ad usare il secondo numero non tanto per gli aggiornamenti delle funzionalità, ma per contrassegnare un "full release", cioè uno che è stato testato e superato. Quindi aggiorno quel valore e ripeto l'alternanza tra dev e test, incrementando ogni volta il terzo numero fino a quando non passa tutto.

Buone risposte già fornite, ma troverei anche un modo per incorporare il git sha1 nella tua applicazione, così puoi scoprire che era git commit 1b5619273127398123 che era quello usato in questa particolare versione. In questo modo, se il signor Smith di BigCo chiama e lamenta che la sua app non funziona correttamente, puoi chiedere "Qual è la lunga fila di cifre e lettere sul secondo wor quando fai clic su Informazioni?" E git checkout NNNNNN su ottenere esattamente quella versione, poi fare gli stessi passi di Mr Smith e (si spera) riprodurre il problema. Non c'è niente di peggio che cercare di trovare un problema che non puoi riprodurre perché stai usando una versione leggermente diversa (dove per caso o di proposito eviti quel particolare problema).

Assicurati inoltre che il tuo sistema di build sia incluso nella versione - preferibilmente includendo la versione del compilatore e così via - sia codificato che memorizzando quali strumenti di compilazione usi quando crei il prodotto all'interno del tuo repository git.