Perché utilizzare il numero di build al posto del versioning x.x.x in un'app Web è una cattiva idea?

Sembra che tu sia il consumatore solitario del tuo codice applicativo in modo da non aver bisogno della versione semantica del software. L'utilizzo dei numeri di build ti consentirà di modificare il codice tutte le volte che desideri senza rompere nessuno. Inoltre ci sono strumenti di compilazione che non usano nemmeno input semantici per spezzare la cache, ma solo generare un hash del contenuto del file e includerlo nel nome del file.

Ora, se inizi a scrivere altri spinoff della tua applicazione che si basano su librerie comuni o crei qualche sorta di sistema di plugin di terze parti pubblico, allora sì, userei il versioning semantico. Se è necessario in futuro, è probabile che possa essere aggiunto in modo banale.

Is there anything I am missing here?

Sì. Ti manca il fatto che sei umano e non hai una perfetta previsione. Un giorno scoprirai che hai fatto molte cose che erano semplicemente sbagliate o che ti impedivano di progredire.

Quando ciò accade (e succede a quasi tutti i progetti software di complessità sufficiente), dovrai interrompere la compatibilità all'indietro. Hai bisogno di un meccanismo per dire ai tuoi utenti che (per esempio) la release # 13 fornisce una serie di nuove funzionalità, corregge un numero enorme di bug precedentemente non risolvibili, ma lo fa a costo di richiedere agli utenti di riscrivere parte del software che usa il tuo pacchetto.

Il numero di build, che conta monotonicamente da uno (o zero) pending di mani, non comunica molto. Hai bisogno di qualcosa che dica agli utenti del tuo pacchetto quanto lavoro debbano fare per trarre vantaggio dalla tua ultima versione. Come minimo, ti consigliamo di utilizzare uno schema di numerazione major.minor . Questo può essere sufficiente se il progetto rimane piccolo. Nota che il numero di build è assente da questo schema.

Se il tuo progetto ha la possibilità di crescere oltre un progetto di una sola persona, potresti voler passare a uno schema di numerazione major.minor.patch . Questo è l'approccio adottato nel versioning semantico . Ancora una volta, il numero di build è assente da questo schema.

Dire agli utenti che potrebbero dover riscrivere pezzi significativi del loro software che utilizza il pacchetto (un bump nel numero di versione principale) trasmette molte informazioni. Dire agli utenti che hanno bisogno di osservare il comportamento su cui si sono basati è stato un bug (un bump nel numero di rilascio minore) che trasmette anche molte informazioni. Raccontare ai tuoi utenti quel comportamento che tutti hanno evitato fino ad ora perché tutti sapevano che il software utilizzato per soffocare (un bump nel numero di patch) trasmette anche molte informazioni.

Il numero di build, d'altra parte, non fornisce molte informazioni.