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

3

Ho rilasciato l'API 1.0.0 nel ramo principale (ramo predefinito). Da allora ho separato separatamente i rami api2/foo e api2/bar , entrambi contenenti modifiche non compatibili all'indietro.

La versione dell'API è dichiarata nel codice sorgente. Dovrei eseguire il bump della versione a 2.0.0 in entrambi i rami api2 / * o nel ramo principale?

Se eseguo il bump della versione nel ramo master, le versioni nel codice sorgente sui rami api2 / * non verranno aggiornate. Se devo rilasciare build di sviluppo per i rami, le cose in API 2 possono essere utilizzate quando il progetto dichiara di essere API 1. Di conseguenza, devo unire il commit nel ramo master che esegue il dump della versione, ma io farò un mege altri cambiamenti nel ramo master del tutto, e non voglio che accada ancora.

D'altra parte, se eseguo il bump della versione nei rami dev, ci saranno due commit che sbattono le versioni, quindi quando saranno entrambi fusi nel ramo master, ci sarebbero potenzialmente dei conflitti.

Quale sarebbe una buona soluzione tra queste due opzioni?

    
posta SOFe 16.05.2017 - 12:09
fonte

4 risposte

3

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
risposta data 16.05.2017 - 18:51
fonte
4

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.

    
risposta data 16.05.2017 - 14:41
fonte
2

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.

    
risposta data 16.05.2017 - 15:13
fonte
0

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.

    
risposta data 16.05.2017 - 12:17
fonte

Leggi altre domande sui tag