Per semplificare la distribuzione e le attività di gestione dei progetti, mantengo un monorepo contenente diversi pacchetti che hanno ciascuno una semver versione. Per essere chiari, non intendo molti repository gestiti da un unico luogo, voglio dire un singolo repository Git che tiene traccia di diversi pacchetti con una toolchain comune. Nota che questo NON implica che questo sia l'unico repository gestito dal mio team. Gestisco solo quello in questione per una specifica pipeline di consegna.
Il monorepo è di per sé difficile da versionare con semver perché un bump di versione principale in un pacchetto potrebbe non giustificare un bump di versione principale nel monorepo stesso. Prendiamo una GUI che passa da v2.9.3 a v3.0.0 sulla base del fatto che utilizza un nuovo sistema di progettazione che altri pacchetti non usano ancora. Questo non è forse un cambiamento nel monorepo, poiché:
- Il cambiamento di monorepo probabilmente equivarrebbe solo a un'aggiunta di dipendenza.
- Non c'è motivo di allarmare il team con un bump di versione principale per il monorepo che distrae dalla modifica più rilevante nel pacchetto.
La relazione tra le modifiche di versione nel monorepo e i pacchetti sono, in generale, difficili da automatizzare a meno che non si assumano come obiettivi obiettivi altamente specifici o fragili.
Nota che suppongo che due dossi di versione debbano accadere simultaneamente perché se il monorepo non ha una sua versione e tag correlati, allora questo rovina l'output git describe che usiamo per tutta la società.
Quale strategia applicheresti nella mia posizione?
Consentitemi di chiarire alcuni dettagli, in base a ciò che ho letto da altri utenti. Supponiamo che ci siano diverse tattiche in gioco in giro per l'azienda per gestire le revisioni. C'è un monorepo con semiver, ma c'è un altro repository usando i sottomoduli git e l'altro con gli strumenti di distribuzione cross-stack. Data la mia posizione, devo presumere che i suggerimenti per normalizzare su un'opzione siano, sfortunatamente, non attuabili al momento. L'atto di scindere o combinare i repository è un cambiamento di rottura con un effetto a catena. Questo dovrebbe aiutarti a capire perché sto limitando la domanda all'uso di semere su un repository; è il cambiamento meno costoso nel contesto.