Come versione, con versione semantica, quando viene risolto un bug tra una versione stabile e una versione instabile

dalle specifiche SemVer link

A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version.....

...Pre-release versions have a lower precedence than the associated normal version

... Precedence for two pre-release versions with the same major, minor, and patch version MUST be determined by comparing each dot separated identifier from left to right until a difference is found

Quindi sembra che tu possa avere 1.1.1-rc1 e 1.1.1-rc2

Per essere onesti, penso che questa roba preliminare sia una presa in giro di versioning e testing. Rilascia o non rilascia 1.1.1 e segui la 1.1.2 se correggi un bug.

Se hai più di una versione supportata, assicurati che siano versioni principali diverse o ti servirà il quarto numero di versione.

- Modifica,

Penso che la domanda sia stata modificata un po 'dopo la mia risposta.

re: che cosa dovrei chiamare v1.1.0 + correzione dei bug urgenti, quando 1.1.1-rc1 è già nella pipeline ma non verrà rilasciato abbastanza velocemente per me?

Bene, non c'è una regola che tu debba rilasciare ogni versione, 1.1.1 ha fallito il test, perché sai di sapere di questo errore urgente. rilasciare 'v1.1.0 + fix urgent bug' come 1.1.2-rc1 e poi 1.1.2 come da procedura normale.

Vedo che la tua obiezione sarebbe "ma stiamo parlando della 1.1.1 con una nuova funzionalità, che rilascerà 1.1.2 senza la funzione confonderà i clienti e rivelerà che abbiamo perso questo bug!"

A cui dico, se è una nuova funzionalità dovrebbe essere almeno 1.2.0 se non 2.0.0! la terza cifra è per le patch, non per le funzionalità. Fai la funzione come 1.2.0, 1.2.1 ... ecc. E puoi continuare con le correzioni "urgenti" senza la funzione su 1.1.3, 1.1.4 ecc.

So che alcune aziende sono contrattualmente obbligate a non aggiornare il numero maggiore, se si è in una situazione simile, forse è necessario aggiungere il numero della quarta versione e avere 1.1.1.2?

Non entrare nella situazione in cui si teme di aumentare il numero di versione per indicare correttamente le diverse build. Qualcuno da qualche parte ha quella versione 1.1.1 che hai rilasciato per sbaglio e ha bisogno di 1.1.2 non 1.1.1 (corretto, spero che nessuno se ne accorga !!)

Dovrebbe essere relativamente facile testare e distribuire una patch. Raccomanderei di apportare la modifica in 1.1.1 creando una 1.1.1-rc2 con la correzione di bug critica, di averla completamente testata per il processo di rilascio e di rilasciare 1.1.1 il prima possibile. Forse avevi più correzioni di bug programmate per 1.1.1, ma se c'è un bug critico, potrebbe valere la pena scaricare 1.1.1 più velocemente e poi inserire le correzioni di bug rimanenti in una versione 1.1.2 o 1.2.0 a seconda se è solo correzioni di bug o include anche nuove funzionalità compatibili con le versioni precedenti.

Ecco un approccio che si adatta perfettamente allo schema di versioning SemVer:

• supponiamo per un attimo che il changeset da 1.1.0 a 1.1.1-rc1 abbia introdotto problemi imprevisti, proprio come se i tuoi tester lo trovassero durante i test (non importa che questo non sia vero, comportati come se lo fosse)

• in modo da ripristinare tutte le modifiche da 1.1.0 a 1.1.1-rc1 (che significa: iniziare di nuovo con la base stabile "1.1.0"). Puoi dare a questo codice il numero di versione "1.1.1" se vuoi (sai che è stabile poiché è effettivamente identico a 1.1.0, solo con un numero di versione modificato, quindi non c'è più bisogno di alcuna etichetta "rc" ). Quindi aggiungi solo il bugfix urgente (suppongo che potrebbe essere così urgente che bypasserai il tuo QA normale, almeno sarà testato prima di ogni altra cosa, senza alcuna etichetta "rc"). Secondo SemVer, questo risulta nella versione "1.1.2", la versione che viene rapidamente distribuita in produzione.

• quindi reintrodurre il patchset originale da "1.1.0 a 1.1.1-rc1" in "1.1.2". Secondo SemVer, questo diventa "1.1.3". Aggiungi "-rc1" di nuovo se preferisci questo e distribuilo nel tuo ambiente di test.

Quindi la sequenza risultante di versioni è solo la sequenza lineare

    1.1.0          stable baseline
    1.1.1-rc1      unstable test version, containing a changeset A
    1.1.1          stable version, but A reverted (so identical with 1.1.0)
    1.1.2          stable version, including only urgent fix B, but not A
    1.1.3-rc1      unstable test version, containing A and B

Questo segue tutte le regole di SemVer e non è necessario "rinominare" o "relabel" alcuna versione esistente. La versione intermedia "1.1.1" vive solo per un brevissimo periodo di tempo, solo come copia di lavoro per un minuto - o meno - nella postazione di lavoro dello sviluppatore che integra l'urgente bugfix.