Se avessi soddisfatto tutti i requisiti della versione 1.0 e avessi lavorato sulla versione 2.0, le nuove funzionalità sarebbero 1.1, 1.2, 1.3 e così via. Che versione eseguo i commit che rappresentano una correzione importante o una funzione dimenticata richiesta nella versione 1.0? Anche se non avessi corretto le correzioni sulla versione 1.0, ci sarebbero ancora due versioni 1.0.1 fino a quando il ramo di sviluppo si fonde nel ramo principale.
Se continui a sviluppare su 1.0 allora 2.0 dovrebbe essere un fork. Apportare modifiche in 1.0 dopo il fork ti frammenterà, qualunque cosa tu faccia.
Python ha incontrato questo problema e fino ad oggi Python 2 e Python 3 sono stati considerati come lingue diverse.
Se non vuoi frammentare dimentica 1.1 e metti tutto in 2.0. Non importa nemmeno se 2.0 non è ancora stato pubblicato. Se crei una situazione in cui stai correggendo i bug in due punti sei frammentato.
Non è che non puoi frammentare. È che i costi della frammentazione ti insidieranno. I moderni sistemi di controllo delle versioni possono contribuire a mitigare alcuni di questi aspetti, ma anche i soli costi per i test rendono la frammentazione una situazione difficile da giustificare.
Supponendo che la versione 1.0 sia rilasciata, la domanda è se si prevede di rilasciare le correzioni, le funzionalità dimenticate ecc. In tal caso, deve essere una nuova versione dire 1.0.1 o 1.1
Altrimenti puoi incorporare tutti questi nella prossima versione da rilasciare. Come altri hanno detto che non dovresti inviare diversi pacchetti della stessa versione.
In ogni caso, penso che dovresti sviluppare un atteggiamento mentale, politiche e pratica per lavorare sulle nuove versioni. Ciò manterrà il tuo codice ben organizzato in un sistema di controllo della versione. Controlla il materiale per il controllo delle versioni semantiche. Fornisce un buon approccio a molte domande come questa
Sembra che tu abbia già una pratica di "rilascio" di una versione unendo develop in master con un nuovo tag. Questo è tanto granulare quanto è necessario ottenere. Potresti avere diverse modifiche che vengono pubblicate e unite a develop durante il ciclo di rilascio, ma ognuna non richiede necessariamente un aumento della versione; la versione dovrebbe salire solo alla successiva unione fino a master , e il set di modifiche della versione sarebbe l'aggregato dei ticket che scendevano tra l'ultima fusione da develop a quella corrente.
Leggi altre domande sui tag version-control semantic-versioning