Quando e come fare un rilascio?

Non è mai esplicitamente enunciato, ma un'attenta lettura di semver.org suggerisce che una versione è associata a una versione corretta, non a un commit VCS . Quindi, naturalmente, se crei una one che ha più correzioni di bug, aumenti il componente di patch una volta . Lasciare ampi spazi vuoti per tenere conto degli stati intermedi che non hanno una versione (nemmeno in linea di principio, come le versioni interrotte che sono state ritirate) non ha senso.

Ovviamente potresti fare un rilascio per ogni singola piccola modifica, ma probabilmente non è desiderabile: è un lavoro molto per te, spreca tempo e larghezza di banda dell'utente con frequenti aggiornamenti, e risulta in numeri di versione ridicoli e rilascia log. Ci sono varie politiche per quando rilasciare, e che funziona meglio è soprattutto una questione di opinione e le peculiarità del progetto e della sua base di utenti. Alcune opzioni comuni sono:

• Alcuni progetti rilasciati una volta ogni X unità di tempo, indipendentemente da quante o poche modifiche sono state fatte.
• Alcuni progetti vengono rilasciati una volta raggiunta una soglia soggettiva di "modifiche sufficienti".
• Alcuni progetti hanno delle pietre miliari: "Rilasceremo vX.Y una volta che avremo questa cosa e questa cosa sarà fatta".
• Un mix di quanto sopra.

La maggior parte dei progetti, anche quando normalmente aderiscono a uno dei precedenti, può rilasciare hot fix fuori linea quando un particolare bug è stato rilasciato in natura.

Al contrario, se pubblichi nuove versioni così raramente (o mai) che la maggior parte delle persone semplicemente traccia git master , allora non riesci a seminare perché queste persone non ottengono alcuna garanzia di compatibilità all'indietro. La correzione non consiste nel dare a ogni commit il proprio numero di versione, ma a rilasciare in intervalli più sensibili.

Attenzione che se CakePHP 3 sta cambiando la sua API plugin (e il tuo plugin si adatta a tale modifica), probabilmente dovresti aumentare il tuo numero maggiore.

BTW, in MELT sto nominando esplicitamente la versione (i) di GCC per cui è stata creata questa versione. Quindi li chiamo MELT-1.1.3 per GCC 4.8 o 4.9

I plugin sono un caso d'angolo del versioning semantico, perché ciò che di solito importa è sia la versione del plugin, sia la versione (accettabile) del programma che usa quel plugin.