Le versioni devono essere urtate nei rami dev o nel ramo principale?

Versione del codice quando si crea una versione sul proprio server CI.

Normalmente questo sarebbe su un check-in per lo sviluppo, master se non si dispone di un ramo di sviluppo

Se esegui la versione dei rami di funzionalità, avrai dei problemi in quanto non esiste una definizione chiara di quale sia la versione "più recente".

Poiché ti manca il ramo di sviluppo, ed entrambe le modifiche sono incompatibili dovrai:

• unisci foo in master, crea v2
• Unisci master in barra, correggi incompatibilità
• Unisci barra in master, crea v3

La domanda di fondo è: che cos'è una buona dimensione di commit?

Il mio consiglio è: un commit dovrebbe contenere una modifica singola ma completa.

"Singolo" indica la minor quantità possibile di linee modificate.
"Completato" significa che il progetto viene compilato e tutti i test automatici sono stati eseguiti correttamente.

In questo senso il "bump della versione" è un cambiamento singolo ma completo.

Se quella "versione bump" fosse in un commit separato, potresti semplicemente rimuovere (saltare) quel commit di git rebase -i prima di unire.

A mio parere, non sarebbe saggio aggiornare a 2.0.0 in entrambe le filiali separatamente, perché ciò implicherebbe che entrambi rappresentino la versione 2.0.0. Ma questa è chiaramente una contraddizione, perché sono incompatibili tra loro. Innanzitutto, avere due build incompatibili con lo stesso numero di versione sconfigge l'intero scopo del controllo delle versioni!

Dovresti unire entrambi in un ramo di rilascio oppure unire foo nella barra (o viceversa) e quindi eseguire il bump della versione su 2.0.0. Puoi quindi unirlo di nuovo in master.

Il modo in cui scegli di farlo dipende da come appare la tua pipeline.

Non dovrebbe esserci modo di iniziare accidentalmente a utilizzare una versione incompatibile, se in precedenza si utilizzava una versione rilasciata stabile. Ciò significa che il numero di versione deve essere cambiato prima della prima opportunità di creare un artefatto che viene distribuito (una build locale da parte di qualsiasi sviluppatore che lavora sulla funzione andrebbe bene).

Potresti avere una pipeline in cui l'unico modo per creare un artefatto che potrebbe essere usato da qualcun altro è eseguire un lavoro sul tuo build server che richiede di specificare una nuova versione, facendo in modo che il server di build spinga un commit con il numero di versione aggiornato.

Potresti implementare uno schema di controllo delle versioni che impedisce gli aggiornamenti automatici ai rami "in corso", ad es. assicurati che qualunque gestore di dipendenze tu usi non aggiorni automaticamente alle versioni con qualificatori, e abbia una politica che tutti i checkout dovrebbero immediatamente aggiungere un qualificatore come " -branch-name " al numero di versione (se hai una pipeline automatizzata, potrebbe aggiungi invece quel qualificatore per ogni build).

Dato che hai già le filiali e sembra che tu non abbia nessuna altra soluzione in atto, contrassegno entrambe le diramazioni come "2.0.0-SNAPSHOT", le unisco e quindi esegui il bump su "2.0.0". Fare la stessa modifica due volte non dovrebbe causare un conflitto di unione e, se ce n'è una, la risoluzione dovrebbe essere banale. L'utilizzo di un qualificatore "SNAPSHOT" impedirà il conteggio della versione come "full" 2.0.0 (nella maggior parte dei manager delle dipendenze con cui ho familiarità) ed è una chiara indicazione per gli umani che si tratta di un work in progress, mentre il 2.0. 0 ti consente di mostrare che non è retrocompatibile.