Rilasciare i rami e il controllo delle versioni del tronco

Grazie ad altri utenti della risposta siamo finalmente d'accordo sul sistema di controllo delle versioni.

L'idea è di avviare la versione di test con il numero di versione (ad esempio 1.1.0.1 significa "versione di prova per 1.1.0 release") e rimuovere Test al termine del test.

Tipicamente la versione è crescente

1.1.1 --- 1.1.0.1 --- 1.1.0.2 --- 1.1.0.3 --- ... --- 1.2

E inizieremo in modo diverso e faremo reset alla fine

1.1.1 --- 1.2.0.1 --- 1.2.0.2 --- 1.2.0.3 --- ... --- 1.2

L'immagine:

• Laversionedelramodirilasciocontinueràdallaversionedeltrunk.
• Laversionedeltrunksaràripristinatainx.x.0.1.
• Dopoilrilascio,laversionediprovavienereimpostatasux.x.x.1,dovex.x.xèprossimaversione.
• LeversionidirilasciosiottengonocancellandoilTestnumero(significa"il test è finito").

Esistono due strategie principali che affrontano entrambi i tuoi problemi.

1. Il tronco ha un numero di versione "fisso"

Potresti scegliere di assegnare al trunk un numero di versione 0.0.0.X, in cui cambia solo la X. Questo rende quindi chiaro a tutti che tali build fanno parte dello sviluppo attivo e non fanno parte della stabilizzazione di un rilascio.

In questo concetto, non ha senso tracciare (usando i numeri di versione) quando le correzioni di bug di versioni precedenti vengono unite nel trunk.
Ha anche il vantaggio che devi solo decidere quale numero di versione rilasciare (incrementare il minore o la parte principale) quando avvii la stabilizzazione.

2. Il ramo di rilascio continua dove Tronco terminato

Se vuoi che i tuoi metodi di lavoro siano il più vicino possibile a ciò che stai facendo, allora puoi semplicemente continuare i numeri di test sul ramo di rilascio.

Se Trunk è alla versione 1.2.0.26 quando decidi di creare il ramo di rilascio 1.2, la prima build su quel ramo di rilascio sarà 1.2.0.27 (e la successiva su Trunk 1.3.0.1)

In questo schema, puoi semplicemente incrementare la parte BugFix della versione su Trunk quando unisci le correzioni dei bug di versioni precedenti.

Questo schema utilizza essenzialmente una diversa immagine mentale dei rami

------------------------  release 1.1
     \
      \-----------------  release 1.2
            \
             \----------  trunk (to become release 1.3)

Quando si avvia la stabilizzazione per un rilascio, si rinomina Trunk nel ramo di rilascio e quindi si crea un nuovo Trunk da quel punto per lo sviluppo della prossima versione.

Diciamo che il tuo tronco è a 1.3.0.3. Ora crei un ramo di rilascio per la linea "1.3", il che significa che il ramo inizia con quel numero, 1.3.0.3 . In modo simultaneo, si imposta il trunk su 1.4.

Il processo di stabilizzazione nel ramo "release" incrementa quindi 1.3.0.4, 1.3.0.5, 1.3.0.6, forse "1.3.1" e così via - mantiene sempre fisso il numero "major.minor". / p>

D'altra parte, il tuo trunk sarà versionato come 1.4.0.1, 1.4.0.2 e così via. Quindi il tuo bagagliaio ha sempre un numero "major.minor" più alto di ogni altro ramo di rilascio, il che significa che non c'è collisione.

Se si uniscono le modifiche da un ramo di rilascio nel bagagliaio, si aumenta il numero di versione del bagagliaio proprio come avviene con un cambio diretto nel bagagliaio. Il tuo VCS (TFS) potrebbe supportare la documentazione da cui la revisione ha fuso le modifiche nel trunk, e in caso contrario, hai sempre la possibilità di scriverlo manualmente nel log della cronologia (semplicemente un commento come "unite le seguenti modifiche da 1.3.0.6 di nuovo nel bagagliaio: ... "). E questo è il posto in cui appartiene, non proverei a mappare tali informazioni nel numero di versione.

Le due soluzioni che ho trovato per questo:

1. Come da Bart van Ingen Schenau, il suggerimento "Release branch prosegue dove Trunk termina" - fondamentalmente lo stesso di quello che stai facendo al momento, ma non resetti il bugfix e test i componenti del numero di versione quando crei il ramo di rilascio.

2. Come per il kernel di Linux utilizzato per la versione, eseguire il bump della versione secondaria sia prima che dopo aver creato il ramo di rilascio. Ciò significa che esiste un numero di versione secondario specifico sul trunk o su un ramo di rilascio, ma non su entrambi. Non conosco le ragioni esatte per cui il kernel di Linux non è più numerato in questo modo, ma potrebbe suggerire che abbiano riscontrato problemi con esso.