Come contrassegnare la prossima versione nel codice sorgente? [chiuso]

Question

Come contrassegnare la prossima versione nel codice sorgente? [chiuso]

#1 da (4 voti)
#2 da (3 voti)
#3 da (2 voti)
#4 da (2 voti)
#5 da (0 voti)
#6 da (0 voti)
#7 da (0 voti)

1

Stiamo sviluppando un software che viene rilasciato ogni pochi mesi ed è una versione principale ( 1.0.x - > 2.0.0 ) o una versione minore (- > 1.1.x ). Questa versione è visibile nel software, diciamo che abbiamo una variabile come questa:

var version = '1.0.0';

e poi viene visualizzato in qualche modo:

print(version);

Quando rilasciamo 1.0.0 e iniziamo a lavorare su "vNext", è semplicemente sbagliato lasciare 1.0.0 lì perché tutti gli sviluppatori e i tester vedranno una versione "sbagliata" nell'app. Tuttavia, a quel punto non siamo sicuri di quale sarà la prossima versione: potrebbe essere 1.1 o 2.0. Ho pensato forse solo a contrassegnare la prossima versione come "DEV" in modo che non ci sia alcuna aspettativa di un certo numero di versione, ma non sono sicuro che questa sia una buona idea (e non è certamente nel formato semirigido, quindi qualche altro codice potrebbe essere rotto se funziona con il numero di versione in alcun modo). Un'altra idea era quella di chiamarlo "post-1.0" ma non è nemmeno un formato di versione appropriato.

Ti sei mai imbattuto in questa situazione e in che modo ti sei comportato con esso?

versioning

posta Borek Bernard 17.04.2015 - 12:24

fonte

7 risposte

Leggi altre domande sui tag versioning

Come impostare un avvio agile senza il cliente? [duplicare] La procedura migliore per passare la stringa formattata ai metodi

score 4 · Answer 1

Usi la configurazione della build per compilare la var.

La maggior parte dei motori di compilazione consente il passaggio di un file di ricerca e sostituisce il file risultante.

Quindi la riga effettiva nel repository sarebbe

var version = @VERSION@;

E poi attraverso le impostazioni di configurazione del builder @VERSION@ verrebbe sostituito con la versione effettiva al momento della costruzione (possibilmente aggiungendo i postfix e il commit ID di debug per i build di test).

score 3 · Answer 2

Una risposta standard a questo è nel mondo dei Maven. Le versioni di sviluppo utilizzano il numero di versione successivo con il suffisso "-SNAPSHOT". Ad esempio, dopo un rilascio di 1.0.2, Maven incrementa automaticamente la versione su 1.0.3-SNAPSHOT.

score 2 · Answer 3

Ecco un modo semplice per farlo. Dal momento che deve essere una versione più alta della corrente, l'incremento minimo richiesto è una versione minore. Usalo per iniziare.

Se in seguito si decide di cambiarlo in una nuova versione principale, cambialo di nuovo.

Perché renderlo più complesso?

score 2 · Answer 4

Sviluppo in un ambiente strongmente integrato, quindi aggiungerò un'altra opzione:

I nostri dispositivi dispongono di un comando di query per acquisire la versione del firmware e restituiscono il risultato con un numero di 2 byte in caso di successo. Il problema con le risposte di cui sopra è che potrebbe non essere pratico aggiungere tag come "pre" quando sei limitato sul tuo formato di output dei dati.

Quello che abbiamo deciso di fare è aggiungere una maschera binaria al nostro numero di versione che normalmente non ci sarebbe. Ad esempio, una timeline del nostro sviluppo potrebbe essere:

0x0048 (versione stabile precedente)
0x8049 (beta del primo stadio, versione di lavoro 0, bit15 è il flag di prerelease, bit14 - bit12 utilizzato come fasi di sviluppo beta)
0x8149 (beta della prima fase, versione 1 funzionante)
0x9049 (beta della seconda fase, versione operativa 0)
0x0049 (versione pubblica finale)

score 0 · Answer 5

Ero abituato a lavorare su un progetto in cui la versione veniva incrementata dopo ogni funzionalità aggiunta. Abbiamo usato versioning semantico quindi, dopo ogni modifica, abbiamo potuto incrementare la versione a seconda che si trattasse di una correzione di bug, una modifica compatibile o incompatibile. La versione di rilascio era la versione in cui siamo arrivati dopo tutte le modifiche introdotte in questa versione.

Ciò significava che i rilasci non erano "continui": il rilascio successivo alla 4.5.2 potrebbe essere 6.3.1, non necessariamente 4.6.0 o 5.0.0. Questo era OK in quel particolare progetto. Naturalmente se la tua versione viene utilizzata per il marketing per gli utenti finali, probabilmente non ti sarà consentito utilizzare questo schema.

Personalmente, ho trovato questo modo di versionare molto conveniente. Rimuove completamente il problema - ogni versione mostra il proprio numero di versione, non ci sono "versioni intermedie" di cui dovresti preoccuparti.

score 0 · Answer 6

Per questo sono disponibili più approcci, principalmente convenzionali e politici che tecnici in realtà.

Se puoi fare ricerche su ciò che è stato fatto per i grandi progetti open source, potresti trovare molta ispirazione.

Un esempio di ciò che ho fatto per un progetto per cui ho lavorato.

Versioni contrassegnate come Major.Minor.Patch.Build. build è stato generato dal sistema di build in modo che le versioni di sviluppo avessero solo tre numeri mentre le versioni "ufficiali" (cioè create automaticamente dal sistema di build) avrebbero tutte e 4.

La versione in testa sarebbe sempre la versione successiva, quindi se l'ultima versione era 1.3.5, la versione impegnata era 1.3.6.

Se avessimo bisogno di rilasciare una versione minore o maggiore, dovremmo prima impegnare i nuovi numeri di versione, quindi creare la build, quindi eseguire il commit della versione successiva.

Tuttavia, le cose raramente sono perfette la prima volta, quindi quello che è stato fatto è stato:

1 - Ramo a un ramo di rilascio e versione di bump, se necessario (se si rilascia maggiore o minore) 2 - Bump la versione sul ramo principale in modo che rappresenti la prossima versione che verrebbe rilasciata. (sempre si presume che sia una patch sull'ultima versione) Stabilizzare la versione da rilasciare e unire la correzione sul ramo principale. Lavora normalmente sul ramo principale.

Nella nostra situazione la versione è stata contrassegnata in un file (per prodotto) contenente le prime 3 cifre, l'ID build è stato gestito interamente dal sistema di generazione.

Questo è solo un esempio. ci sono molti altri e varianti che puoi usare. Dipende molto dalle abitudini di lavoro dei tuoi team (filiali, ecc.), Dalle capacità del tuo sistema di costruzione, dalla commercializzazione dei tuoi prodotti, ecc., Quindi nessuna soluzione unica si adatta a tutti.

Spero che questo aiuti.

score 0 · Answer 7

Invece di usare un numero magico (variabile) che non è "presente" durante la visualizzazione del codice, suggerisco un altro approccio:

Esegui il controllo delle versioni con le directory, ad es.

/the_project/1.0/src/files
/the_project/1.1/src/files
/the_project/2.0/src/files
/the_project/2.1/src/files

In questo modo quando le persone navigano nel codice non dovrebbero avere dubbi sulla versione in cui si trovano perché fa parte del percorso della directory che stanno cercando.