Ho un programma che è composto da 5 componenti principali. Trovo la numerazione della versione standard troppo limitante, perché mi piacerebbe vedere quale sia la versione di ogni compoment.
Qualcuno ha trovato un modo semplice per fare questo oltre a elencarli separatamente?
Abbiamo esattamente lo stesso problema con il nostro prodotto e abbiamo deciso di fare numeri di versione individuali per ogni componente e la versione del prodotto è solo una versione di marketing che è composta dai vari componenti a una revisione specifica.
Abbiamo una "versione di rilascio del sistema", che è un numero di versione standard che descrive una particolare configurazione di componenti, quindi un file separato elenca le versioni dei singoli componenti per quella particolare release di sistema. I clienti dicono 5.2.1 ma possiamo cercare la singola build se necessario. Solitamente per una versione importante, sincronizziamo tutte le singole versioni in modo che tutto venga creato di nuovo dallo stesso numero di ramo.
Il controllo delle versioni è un problema separato dallo sviluppo di applicazioni basate su componenti. O vuoi la versione di ogni componente, o vuoi la versione dell'intera applicazione.
Un modello ben noto per il controllo delle versioni è Microsoft :
major version.minor version.build number.revision
Ad esempio, puoi vedere i file DLL nella piattaforma .NET per avere versioni come 2.0.3600.1, o qualcosa del genere.
Quindi, prima di tutto, ti suggerisco di stabilire se desideri eseguire la versione dell'intero sistema o dei suoi componenti. Se desideri eseguire la versione dell'intero sistema, dopo ogni integrazione, crea l'intero progetto e aumenta la parte numero build . In caso contrario, quindi semplicemente versione di ogni componente su build.
Fai attenzione al controllo delle versioni, potrebbe ucciderti :-) Non cercare di rendere le cose troppo complicate.
Penso che il seguente approccio potrebbe aiutarti:
Esegui la versione di ciascun componente individualmente con qualsiasi schema di versioning che desideri. Dai tuoi commenti capisco che hai un VCS sul posto. Suppongo anche che ogni componente abbia un file in cui è conservata la sua versione (giusto?). Una volta al giorno / settimana (a seconda di quale funziona meglio per la tua squadra) aggiungi un tag ad una delle revisioni più recenti in VCS che contrassegna tale revisione come l'ultima revisione ufficiale (e facoltativamente incrementa un numero di super-revisione). Ora puoi interrogare il VCS per le revisioni con quel tag e poi cercare la versione dei componenti in quella build ufficiale.
Se vuoi solo localmente, scrivi un piccolo script che aggregherà la versione di ciascun componente dal luogo in cui è memorizzato il codice.
Se vuoi renderlo ancora più elaborato, una volta eseguito il tagging puoi guardare i file appartenenti a ciascun componente, considerando che puoi identificare i file che appartengono a un componente specifico. In caso di modifiche, incrementare la versione per quel componente specifico. L'alternativa è farlo manualmente. Un'altra alternativa è una combinazione di ramificazione e fusione con il monitoraggio della versione.
La maggior parte dei numeri di versione utilizza una revisione principale e secondaria che è guidata dal marketing, quindi non è possibile utilizzarli per il monitoraggio delle singole versioni dei componenti. In breve, è necessario trovare qualche altra parte della versione che è possibile utilizzare per tenere traccia delle versioni dei singoli componenti e riservare i numeri di versione maggiore e minore per tracciare l'intero pacchetto.
Se stai seguendo qualcosa simile al pattern Microsoft:
major-version.minor-version.build-number.revision
Puoi utilizzare .revision per monitorare la versione di ogni singolo componente e utilizzare i numeri di revisione minori e principali per tenere traccia di una modifica completa del prodotto, nel solito modo.
Se stai seguendo uno schema simile a questo:
Major-Version.Minor-Version.Build-Number
Dovrai utilizzare il numero di build per tenere traccia delle versioni dei singoli componenti.
Sono scritti interi libri sul software di controllo delle versioni.
Ecco un approccio che uso.
Ogni parte ha una versione nel formato:
major.minor.developmental
Ciascuno di questi è un numero, a partire da 0.
Per una versione ufficiale (cioè per i clienti), la parte di sviluppo deve sempre essere 0 come criterio.
Major è incrementato dalla decisione di marketing.
Il livello minore viene incrementato in base al rilascio di serie di caratteristiche - sul mercato.
Esempio:
Inizio lo sviluppo su un nuovo componente, quindi il mio numero di versione sarà 0.0.1. Quando esco dalla mia scrivania per i miei colleghi, ad esempio, per i test interni, il numero di sviluppo sale a 0.0.2, 0.0.3 e così via.
Ho rilasciato questa nuova versione sul mercato come 1.0.0, dove l'unica modifica consentita dalla fine dello sviluppo alla versione era quella di cambiare il numero della versione (es. 0.0.43 - > 1.0.0).
Alcune nuove funzionalità devono essere aggiunte. Inizio a lavorare sulla linea di base 1.0.0, aggiungendo queste funzionalità, quindi le versioni che rilascio ai miei colleghi per il test sono 1.0.1, 1.0.2 e così via.
Le prossime funzionalità sono rilasciate sul mercato come 1.1.0.
Il marketing decide che la prossima grande novità sarà davvero grande, quindi uscirà come 2.0.0. Inizio a lavorare su 1.1.1, passando per 1.1.x, e rilascio come 2.0.0.
E così il ciclo si ripete.
Questo approccio, per ciascun componente, ti offre la tracciabilità degli antenati.
Interno del tuo sistema di gestione delle revisioni di origine (e oggetto), usa rami e tag (etichette, qualunque sia la tua terminologia del giorno) per gestire lo sviluppo.
Il tuo controllo di revisione può quindi gestire ogni componente completamente separatamente, con rami di sviluppo e etichette / tag per ciascuno. Oppure puoi raggrupparli tutti insieme, nel qual caso potresti voler ramificare per pacchetto di lavoro - ma assicurati di etichettare / tag per versione di ciascun componente (e quando lo fai, etichetta / tagga tutto, non solo i bit per componente. In questo modo si ha un'istantanea dello stato di tutto alla volta.)
È probabile che il tuo processo di rilascio richieda un'attenta riflessione. L'utilizzo di questo approccio include alcuni passaggi manuali, che potrebbero non essere desiderabili, tutto dipende dal modo in cui il tuo sistema di build inserisce i numeri di versione nell'oggetto finale. Per molto codice incorporato in cui i numeri di versione sono solo numeri con nome (ad esempio #definito in codice C), non hai altra scelta se non quella di fare tutto manualmente in ogni caso. Le piattaforme desktop con una buona GUI spesso rendono questo molto più amichevole.
Per me, l'unico modo affidabile per il software di versione è utilizzare l'hash hash o il changeset dal tuo sistema di controllo della versione.
Un numero di versione di build generale può essere utile, ma è davvero garantito che sia univoco se si dispone di un server di build e / o si firma ogni versione. Per molti di noi però, questo semplicemente non è fattibile.
Se il tuo progetto è suddiviso su più repository di controllo della versione, dovrai anche creare un meccanismo in base al quale l'interfaccia utente può interrogare ogni repository dipendente e riportare il suo hash all'utente.
In un progetto in un precedente datore di lavoro, in cui abbiamo avuto problemi con il nostro software (interno) che modifica il cliente e lo ricompilavo, ho istituito un processo in cui gli hash mercurial venivano compilati in ogni applicazione e libreria. Ogni volta che il software è stato avviato, una stringa di revisioni è stata creata interrogando tutti i componenti software.
Questa stringa di revisione è stata visualizzata quando si è passati alla pagina about e si è scritto nel file di log ogni volta che si avviava l'applicazione. Era nella forma:
Application name (6a72e7c61f54)
Library1 (b672a13a41e1)
Library2 (9cc35769b23a)
Library2 (9cc35769b23a)
Library3 (4e9f56a0186a+)
Library2 (9cc35769b23a)
Library4 (2e3b08c4ac76)
Library1 (b672a13a41e1)
Library2 (9cc35769b23a)
Da questo ho potuto facilmente vedere che avevano modificato Library3 e non avevano commesso tali modifiche al repository, quindi stanno usando un codice che non è controllato. Potrei anche confrontare gli hash con il mio attuale sistema di test, quindi potrei essere in grado di identificare che hanno ripristinato (diciamo) Library1 su una versione precedente.
Questo significava che ogni volta che riportavano un bug, potevo sempre ricostruire esattamente il codice in uso al momento in cui si verificava il problema, o per lo meno sapere per certo che non potevo riprodurre il setup.
Per ulteriori dettagli sul sistema di build che ho usato, su come ho realizzato questo, su quali problemi ho avuto e su cosa le persone hanno suggerito di evitarli, dai uno sguardo al mio Domanda di overflow dello stack .
Nota: questo sistema è realmente valido solo se si utilizza un sistema di controllo di revisione in cui è garantito che un dato hash produca lo stesso insieme di file nella directory di lavoro (es. git e mercurial) se una determinata directory di lavoro può contenere un mix di file e directory da diverse revisioni (es. svn) quindi tutte le scommesse sono disattivate rispetto allo stato della directory di lavoro e questo metodo non funzionerà affatto.
Leggi altre domande sui tag versioning