Version delle app con SemVer

Prima di tutto, SemVer.org riguarda la numerazione delle versioni per librerie e API. Puoi prendere in prestito le idee da utilizzare per le applicazioni, ma nota che non è perfetto (ad esempio, SemVer dice che il numero della versione MAJOR aumenta quando si effettua una modifica API non retrocompatibile)

Non lavori su "FEATURE 2" o "FEATURE 3", lavori su "FEATURE {featurename}".

Supponiamo che tu stia lavorando su Funzionalità A, B e C. Sei alla versione 1.1.0. Se si rilasciano le funzionalità A e C insieme, si passa alla versione 1.2.0. Quando rilasci B (anche se l'hai avviato per primo), vai su 1.3.0.

I numeri di versione sono per i tuoi utenti in modo che possano tenere traccia delle versioni.

Che cosa succede se hai iniziato una grande funzione ma l'hai abbandonata prima del rilascio. Vuoi saltare un numero nella tua versione? (Mai! Confonderebbe gli utenti)

Il versioning semantico è silenzioso sulle roadmap: si preoccupa solo della versione attuale taggata. Nel tuo caso, se la funzionalità 3 è completata prima del previsto, sta a te decidere se renderla in 1.1.0 o se dovrebbe rimanere in 1.2.0.

Per avere quel tipo di flessibilità, però, dovrai considerare attentamente la tua procedura di integrazione / rilascio. Se stai semplicemente unendo tutto al tuo ramo / master di rilascio ogni volta che una funzione viene eseguita, non sarai in grado di "trattenere" una funzionalità per una versione futura.

Un modo per farlo è avere filiali di rilascio. Una volta che inizi a preparare la prossima versione, creerai un ramo fuori dal master o dal trunk che è solo per quella versione. Solo le funzionalità sulla tabella di marcia per quella versione vengono unite in quel ramo. È possibile eseguire contemporaneamente più rilasci simultanei utilizzando questo metodo, in modo che ogni versione futura abbia il proprio ramo.

Con un processo del genere, non succede niente rispetto al tuo controllo di versione quando la funzionalità 3 è completa: viene aggiunta al ramo 1.2.0 e rimane lì finché non sei pronto per rilasciare 1.2.0.

Tuttavia, questo tipo di processo di rilascio può essere complicato rapidamente e talvolta è soggetto a errori: se una funzionalità è completata ma non fa parte di una versione esistente, dove va? Dovresti impegnare le funzionalità sia in un ramo di rilascio che in un ramo di integrazione principale? Perché il lungometraggio 3 è stato promesso in seguito se prima avrebbe funzionato?

Per questo motivo, è normale adottare un approccio agile ed evitare di bloccare le funzionalità a versioni specifiche: ogni volta che una funzione è pronta, passa alla prossima versione, qualunque essa sia. Nel tuo caso potresti:

• tagga una nuova versione dopo che la funzione 3 è terminata, il che significherebbe che la versione 1.1.0 avrebbe la funzione 3 ma non la funzione 2 e la versione 1.2.0 avrebbe entrambe le funzioni
• aspetta di taggare un nuovo rilascio fino a quando non viene eseguita la funzione 2, il che significherebbe che 1.1.0 avrebbe entrambe le funzioni