Supporto di più versioni con Successful Git Branching Model

Question

Nella nostra azienda ci spostiamo da SvN a Git (sì, meglio tardi che mai). Con ciò, cerchiamo anche di semplificare il processo di controllo delle versioni. Per far ciò ho trovato un articolo interessante: Success Git Branching Model di Vincent Driessen.

Per quanto posso leggere dall'articolo, lo sviluppatore presuppone rilasci lineari. Per essere chiari:

v1.0.0 --> v1.0.1 --> v1.0.2 --> v1.1.0 --> v1.1.1 etc 

Il supporto per le versioni precedenti non è menzionato. Ad esempio: supportiamo fino a tre versioni principali perché alcuni client non desiderano eseguire l'aggiornamento. Quindi immaginate abbiamo le seguenti versioni:

v7.0.0 --> v8.0.0 --> v9.0.0 --> v10.0.0 

Quando c'è un bug critico trovato in v8.0.0dopo il rilascio di v9.0.0, abbiamo checkout tag v8.0.0, correggere bug, e unire nuovamente in develop e master rami. Unisci in master ottiene il tag v8.0.1.

Mi sembra in qualche modo strano a causa di due cose:

1. Il master linea temporale sarà simile v7.0.0 --> v8.0.0 --> v9.0.0 --> v8.0.1 --> v10.0.0. Sono assolutamente consapevole che è possibile, ma è anche accettabile?
2. Quando mi unisco hotfix-master (e master è in quel momento a v9.0.0) e l'etichetta con v8.0.1, posso anche ottenere funzionalità introdotte tra il v8.0.0 e v9.0.0?

Grazie in anticipo!

Answer 1

Per me, il tag v8.0.1 deve essere il commit prima dell'unione master. Se desideri applicare la patch alle nuove versioni, anche qui vengono uniti gli altri tag.

v8.0.0 --> v9.0.0 --> v10.0.0 
    \   \   \ 
    v8.0.1 --> v9.0.1 --> v10.0.1/master