Mantenere il test e rilasciare i numeri di versione in sincronia

C'è davvero una sola regola con i numeri di versione - consistenza.

Anche se sarebbe "bello" avere la prima versione ufficiale del tuo prodotto come 1.0 (motivo per cui le versioni beta sono spesso etichettate come "0.qualcosa") non esiste una regola dura e veloce che dice che hanno essere.

Se hai già chiamato la versione beta 1.0, inizia semplicemente ad incrementare da lì utilizzando lo schema "1.0.1" in modo che la prima versione caricata nell'App Store sia almeno di 1.0. Qualunque cosa.

Anni fa un prodotto su cui stavo lavorando era etichettato "4.0" per la sua prima versione - per rendere il prodotto "più maturo" ai potenziali clienti. Probabilmente non è possibile farla franca in questi giorni, ma non ha sollevato nessuna domanda a cui non avremmo potuto rispondere.

Regole pratiche. Utilizza sempre numeri di versione crescenti. Mantenere sempre sincronizzati i numeri di versione tra le versioni. Non dichiarare mai nulla di definitivo fino a quando non è veramente definitivo.

Nel tuo caso, se vuoi che la versione iniziale di iPhone sia 1.0, devi interrompere una di quelle regole. Se hai intenzione di infrangere le regole, fallo tutto in una volta. Quindi rendi la tua prossima versione 0.9, spiegala ai tuoi utenti beta (che, con un po 'di fortuna, sono il gruppo più piccolo con cui avrai mai a che fare), e procedi da lì. Non etichettare nulla 1.0 finché non è pronto per il rilascio. (Non solo tu pensi che sia pronto, in realtà pronto.)

Per inciso, sarebbe sorprendente se non dovessi fare questa correzione di bug più volte. C'è sempre più da fare di quanto pensiamo che ci sarà.

Probabilmente sarebbe stato meglio avere la versione beta avviata come 0.qualcosa, poiché questo è uno standard di fatto che indica che qualcosa non è ancora stato rilasciato. Non è davvero un grosso problema, però. Una volta che hai iniziato i numeri di versione, non vale la pena cambiarli.

Probabilmente mi piacerebbe rilasciare l'app alla 1.1.4 o qualsiasi altra versione in cui ti trovi dopo la correzione dei bug. A nessuno interesserà veramente questo.

In futuro, potresti voler eseguire il beta test delle versioni aggiornate del software prima di rilasciarle. Dovresti pensare a un modo coerente per gestirlo nel tuo schema di versioning. Un modo comune è 1.2-b1, ecc. Tuttavia, non esiste uno standard per questo. C'è un numero ridicolo di schemi di controllo delle versioni .

Un approccio a questo è quello di avere il numero di versione dell'App Store ufficiale di "1.0" e di avere un numero di build separato da utilizzare per tenere traccia delle modifiche. Finché il numero di build è facilmente accessibile e tutti comprendono il sistema, ti dà una certa flessibilità utile.

(e Apple ti richiede di fornire a ogni versione rilasciata su App Store un nuovo numero di versione, quindi non puoi mai finire con due diverse app live etichettate "1.0")

Right now I have sent out the first beta-test for my users and I have labeled that release as 1.0 for my testers.

Lo chiamerei 1.0-beta1 .

Should I label the release as 1.0.1 then?

Lo farei sicuramente.

What version number should I release this under in the App Store?

Poiché nulla è cambiato dopo aver risolto bug scoperti, dovrebbe rimanere lo stesso - 1.0.1 .

First thought is that since it's the first release to the App Store it should have version number 1.0 but then it will be "out of sync" with the version that has been tested (1.0.1).

I numeri di versione non sono sincronizzati, ma le versioni stesse - che ora sono diverse a causa di bug corretti. Sono diversi, quindi i numeri devono essere diversi .

Trovo che lo schema di versioning semantico sia il più chiaro: link

Una soluzione che sta funzionando per me è incrementare il campo di build (CFBundleVersion) ogni volta che effettuiamo una versione interna al team di controllo qualità e lasciando il campo Version (CFBundleShortVersionString) con quello che chiamiamo 'versione di marketing' e lasciamo il team di business per decidere quale sarà il valore.

Nel tuo esempio pubblicheremo per la prima volta agli utenti beta con versione 1.0 e build 1. Dopo aver ricevuto il feedback e risolto alcuni problemi, rilasceremo al team beta una nuova build con la versione ancora a 1.0 ma la build ora sarà 2. Dopo il rilascio su Apple Store, invieremo le versioni agli utenti beta con versione 1.0.1 (o 1.5 o 2.0, qualunque sia il prossimo obiettivo) e con build 3, incrementando sempre il numero di build su ogni versione.

Funziona bene perché TestFlight mostra la build accanto alla versione, ad esempio 1.0 (2), e inseriamo la versione e il numero di build in una casella about all'interno della nostra app.