Su tests-passed, a partire da 3.2.0.beta1-dev, i numeri di versione di Discourse core includeranno un suffisso -dev per indicare che non si tratta delle versioni finali di “rilascio” di una beta. Questo suffisso non appare nell’interfaccia utente, quindi si tratta di una tecnicalità che non avrà alcun impatto sulla stragrande maggioranza delle persone.
Per i dettagli tecnici, vedi sotto:
Nella serie beta di Discourse 3.1 e versioni precedenti, la nostra strategia di versioning consisteva nel “rilasciare” una beta, e poi lasciare il numero di versione in tests-passed esattamente lo stesso fino al rilascio della beta successiva. Questo presentava alcuni problemi:
-
Nel tentativo di specificare una versione, una versione come
3.1.0.beta2poteva riferirsi a centinaia di possibili punti nel tempo. Questo è particolarmente problematico quando si cerca di definire con precisione la compatibilità tramite file .discourse-compatibility -
Dopo una versione principale, abbiamo dovuto immediatamente “rilasciare” la beta1 della versione successiva per continuare lo sviluppo su
tests-passed. Questo è il motivo per cui abbiamo avuto rilasci beta1 ridondanti
Per migliorare la situazione, ora aggiungeremo -dev al numero di versione durante lo sviluppo di una release beta. Ad esempio, stiamo iniziando il ciclo di sviluppo 3.2 con 3.2.0.beta1-dev. Quando sarà pronto per il rilascio, verrà contrassegnato come 3.2.0.beta1, e poi seguiremo immediatamente con un altro commit per iniziare lo sviluppo di 3.2.0.beta2-dev.
In futuro, intendiamo che le “major release” assomiglino a questo:
%%{init: { 'logLevel': 'debug', 'gitGraph': {'showBranches': true, 'showCommitLabel':true,'mainBranchOrder': 2}} }%%
gitGraph
branch stable order: 1
commit tag: "v3.1.8"
checkout main
commit id: "bump to v3.2.0.beta17" tag: "v3.2.0.beta17" type: HIGHLIGHT
commit id: "bump to v3.2.0.beta18-dev"
commit
commit id: "bump to v3.2.0.beta18" tag: "v3.2.0.beta18" type: HIGHLIGHT
checkout stable
merge main id: "merge"
commit id: "bump to v3.2.0" type: HIGHLIGHT tag: "v3.2.0"
checkout main
commit id: "bump to v3.3.0.beta1-dev"
Le “minor release” assomiglieranno a questo:
%%{init: { 'logLevel': 'debug', 'gitGraph': {'showBranches': true, 'showCommitLabel':true,'mainBranchOrder': 2}} }%%
gitGraph
branch stable order: 1
commit tag: "v3.1.1"
checkout main
commit id: "bump to v3.2.0.beta2-dev"
commit id: "... development of beta2 ..."
commit id: "bump to v3.2.0.beta2" tag: "v3.2.0.beta2" type: HIGHLIGHT
checkout stable
commit id: "backports"
commit id: "bump to v3.1.2" type: HIGHLIGHT tag: "v3.1.2"
checkout main
commit id: "bump to v3.2.0.beta3-dev"
( main e tests-passed possono essere considerati equivalenti in questi diagrammi)
Questi processi sono stati codificati in alcuni task rake che si trovano in version_bump.rake.