Schema del numero di versione per l'applicazione mal pianificata, ramificata e schizofrenica

Question

Sto cercando uno schema/schema/sistema di numerazione versione per un'applicazione attualmente suddivisa in più versioni con date di rilascio stile shell game. Ciò ha reso il versioning un incubo. Mi piacerebbe solo utilizzare il tipico Major.Minor.Revision tuttavia questo si interromperà per me rapidamente il modo in cui le cose sono attualmente corrono qui intorno.

Ecco il mio inventario ...

• 1.0.0 - versione di produzione.
• 1.0.1 - Versione di revisione versione con correzioni di errori.
• 1.1.0 - Produzione minore versione con nuove funzionalità con scadenza luglio (conformità normativa, deve essere fatto).
• 1.2.0 - Produzione versione minore con nuove funzionalità per l'integrazione con non ancora rilasciato-ancora-in-sviluppo sistema A.
• 2.0.0 - Sviluppo importante versione "2.0" del prodotto (codice migrati alla piattaforma più recente, usabilità migliorata).

E per rendere più divertente, stanno progettando un altro progetto (nuove funzionalità) per l'integrazione con un sistema diverso.

• 1.3.0 - Produzione versione minore con nuove funzionalità che integrano con System B.

L'aggiunta alla complessità è il fatto che non sappiamo esattamente quando (leggi: l'ordine in cui) questi "andranno in diretta". Se uno dei sistemi con cui ci stiamo integrando viene ritardato, la gestione modifica la pianificazione del rilascio. Quindi la versione 1.2.0 di oggi potrebbe essere ritardata e quindi la build che abbiamo etichettato come 1.3.0 sarebbe caduta prima. Coordinare con il controllo qualità è già abbastanza difficile senza cambiare le etichette delle versioni alla fine del ciclo.

Domande? Pensieri? Piccoli animali pelosi?

pace | dewde

Answer 1

Mi sembra che tu non voglia utilizzare i numeri di versione in modo specifico. È possibile utilizzare nomi in codice, (Windows ha fatto questo con ciascuna delle loro versioni prima del rilascio). Fondamentalmente hai bisogno di qualcosa di più dei numeri per distinguere nella casa di quale ramo stai parlando. Con il rilascio delle versioni, puoi dare uno schiaffo a Major.Minor.Timbro di revisione su di loro, ma fino ad allora è necessario denominarli in un modo che sarà riconoscibile.

Divide in rami e sotto-rami. Assicurarsi che qualsiasi cosa che dipende da un ramo più alto abbia un nome derivativo. Quindi, è possibile chiamare un ramo ProductionMac e un ramo ProductionWindows, e in questo modo si saprà immediatamente che non devono essere uniti e che entrambi derivano dalla produzione.

La cosa più importante da mantenere è la gerarchia strutturale. I numeri di versione lo fanno abbastanza bene, ma devi continuare ad aggiungere "." per ogni nuovo livello, che è fastidioso e completamente non descrittivo (proprio come nominare le variabili variableOne, variableTwo, variableThree) Quindi, assicurati che comunque tu scelga di etichettare ciascun ramo, è ancora ovvio quali rami sono collegati a quali altri rami.

Answer 2

Suona come numeri non stanno andando aiutare molto, mi piacerebbe andare con nominare i rilasci dopo piccoli animali pelosi.

Oppure, denominare ciascun rilascio dopo il progetto che lo ha generato ("revisione dell'interfaccia utente", "manutenzione di giugno", ecc.) E quindi assegnargli un numero di versione solo quando è attivo?

Answer 3

Vorrei utilizzare un dizionario per mappare tra numeri di sviluppo interno e numeri di "rilascio" esterni, quindi utilizzare internamente i numeri di sviluppo interno e solo esporre i numeri di "rilascio" quando si è pronti a rilasciarlo dallo sviluppo.

Punti bonus se si utilizza una mappa intermedia utilizzando numeri irrazionali. "Come procede lo sviluppo sulla versione 3.14159?" "Oh, non male, ma sto ancora sistemando un bug che abbiamo trovato nella versione 2.71828183." "Cosa? Quel bug? Questo doveva essere risolto con una versione minore 1.73205!" :-)

Answer 4

Sulla base di ciò che descrivi, sono d'accordo con il primo paio di post. I nomi significativi e univoci relativi allo scope/set di funzionalità sono probabilmente la strada da percorrere per ogni ramo. Le versioni numerate sembrano ragionevoli all'interno di ogni ramo nominato.

Che cosa davvero necessario ... è l'etichettatura in stile Gmail ... per la tua versione!

Answer 5

Come altri hanno suggerito, utilizzare internamente un nome in codice non numerico e applicare un numero man mano che ciascun componente viene rilasciato.

L'aggiunta di un numero di revisione/build al proprio controllo di versione può aiutare ad abbinare questo nome in codice interno al numero di versione esterno (e può aiutare nella comunicazione con il QA).

Ad esempio:
R1234 RegulationCompliance corrisponde al 1.1.0.1234 rilascio.

Answer 6

n ai post precedenti.

Il nostro sistema di build incrementa il numero di build dopo ogni build (indipendentemente dal fatto che venga rilasciato o meno), che è ciò che dev/QA utilizza per identificare le build. La versione finale # è ESCLUSIVAMENTE esposta al mondo esterno quando rilascia QA. Quindi esistono più build di 1.3.0.x, ma solo una vera 1.3.0.

Answer 7

Ecco un'altra alternativa che ho preso in considerazione mentre mi ribollisco ieri. Forse ho bisogno di ripensare a ciò che è considerato maggiore. L'integrazione con un altro sistema può essere una piccola quantità di lavoro, ma se impatta la pianificazione e le date di rilascio e la versione in modo significativo, come fa per me qui, forse questo da solo è un impatto abbastanza grande da colpire il ramo fino a stato principale. Quindi alcuni dei miei mal di testa sarebbero stati ridotti al minimo.

Gli scenari più probabili per il rilascio di versioni fuori servizio ruotano attorno alle iterazioni minori minori. I principali adottano uno sforzo coordinato e interdipartimentale. Li puoi vedere all'orizzonte.I minori minori ti avvicinano di soppiatto.

"Ecco il nuovo conformità regolamenti. Se non andare a vivere da 15 luglio, ci sarà multato $ 500.000. al giorno."

"Cosa? Quando hai prese?"

"Lo scorso luglio. Non eri in copia per conoscenza la distribuzione ?"

** ** facepalm

Penso ancora che la risposta di Devinb è la cosa migliore. Ma volevo buttarlo qui per gli altri in questo dilemma.

pace | dewde