Versioning diversi sapori creati da una fonte condivisa

Question

Versioning diversi sapori creati da una fonte condivisa

#1 da (2 voti)
#2 da (0 voti)
#3 da (-1 voti)

1

Ho bisogno di consigli su come creare versioni basate su codici condivisi e separati allo stesso tempo. Ho un progetto gradle con più sapori. Gran parte del codice è condivisa. Alcune parti sono specifiche per il sapore. A seconda del gusto che scelgo, viene incluso il codice corrispondente.

Attualmente utilizzo il controllo delle versioni semantico. v1.2.0 è stato rilasciato prima di introdurre qualsiasi aroma. Ora, se applico un codice per aromatizzare un codice specifico, potrei rilasciarlo come 1.2.1. Ma la prossima volta cambierò il codice condiviso, se tutti gli aromi saranno rilasciati come 1.2.2? Ciò farà in modo che alcuni sapori saltino le versioni in futuro.

D'altra parte, se uso numeri di versione separati per ciascun gusto, sarà difficile tenere traccia delle modifiche comuni solo per le versioni. Ad esempio, ogni aroma avrà una propria versione di correzione per un bug specifico.

In alternativa, potrei mantenere una singola versione interna per il codice comune e versioni separate per ogni aroma che può andare fuori sincrono. Ancora una volta, ciò renderebbe un po 'complicato tenere traccia delle funzionalità e correzioni di errori comuni.

Quale pensi sia l'approccio migliore?

versioning semantic-versioning

posta black 28.09.2018 - 20:35

fonte

3 risposte

Leggi altre domande sui tag versioning semantic-versioning

Progetta la soluzione scalabile con la coda Risoluzione degli argomenti del BDD Scenario: il tipo di file è un input prerequisito per lo scenario

score 2 · Answer 1

Mi sembra che tu abbia un codice di libreria condiviso che fa parte di 1 o più prodotti (sapori). Personalmente, farebbe la versione indipendente del codice della libreria. Ad esempio, se il codice della libreria è composto da 3 moduli, ognuno di essi può essere versionato in modo indipendente dopo il controllo delle versioni semantiche.

Ogni prodotto può quindi dichiarare quale codice di libreria utilizza e la versione con cui è progettato. Ogni prodotto avrebbe anche la sua versione semantica.

In questo modo puoi sviluppare ogni modulo in modo indipendente, supportando diversi cicli di rilascio dei prodotti.

score 0 · Answer 2

Inizierò dicendo che è OK saltare le versioni. Microsoft l'ha fatto saltando da Windows 8 a Windows 10, è successo con Apple OS X. Al giorno d'oggi non è raro avere salti di numeri tra le versioni.

Dico questo per dire questo: se non intendi cambiare il modo in cui costruisci la tua libreria , consenti solo i salti nelle versioni e è OK .

Suggerirei di suddividere il codice condiviso dal codice aromatizzato. Vedete esempi di questo in diverse librerie in cui si aggiunge il supporto per diversi framework (sapori) a strati. Ad esempio:

Fantastico.Amazelib.Core - tutte le cose comuni
Fantastico.Amazelib.NInject - aggiunge il supporto per il framework NInject
Fantastico.Amazelib.MicrosftDI - aggiunge il supporto per l'integrazione delle dipendenze di MS

Ecc. Dovresti ottenere la deriva. Con questa disposizione, la tua libreria principale potrebbe non cambiare molto o potrebbe cambiare più spesso rispetto ai diversi sapori. Non importa. Puoi metterli in versione in modo indipendente e gli utenti possono approfittare degli aggiornamenti quando scelgono.

score -1 · Answer 3

Una versione tipica è W.X.Y.Z

W = Maggiore X = Minore Y = sapore Z = Build

Mantieni una struttura principale o master in cui gli aromi si fondono e le modifiche comuni si uniscono alle versioni di sapore.

Esempio:

Master / Trunk

Versione

1.0.0.0, prima build 1.0.0.1, seconda build 1.0.0.2

Trunk Flavor 1

1.0.1.0, prima build 1.0.1.1. etc

Trunk Flavor 2

1.0.2.0, prima build 1.0.2.1 ecc.

Ciò ti consentirà di identificare da quale versione principale / tronco è derivato un sapore.

Se avessi dovuto battere il master lo avresti fatto:

1.1.0.0, quindi tutti gli aromi che possono provenire da quel master sarebbero:

1.1.1.0 1.1.2.0 ecc.

Se unisci il tronco in qualsiasi sapore, il prossimo numero di build rappresenta la versione che include il tronco cambia e viceversa torna al tronco. Le versioni Major / Minor / Flavor non cambiano in caso di unioni, solo la build incrementa man mano che l'unione viene trattata come un'altra modifica del codice.