Come funzionano i numeri delle versioni precedenti per i nuovi prodotti?

Attualmente sto scrivendo una piccola applicazione desktop per un amico, ma lo sto facendo principalmente come esperienza di apprendimento per me stesso. Nello spirito di essere istruito e fare le cose nel modo giusto, voglio avere i numeri di versione per questa app.

La mia ricerca ha portato a questi risultati correlati

• Quale "convenzione di denominazione della versione" usi?
• Come si effettua la versione dei file (numeri di versione)
• Forked un progetto, da dove iniziano i miei numeri di versione?

ma nessuno di essi affronta la numerazione di alfa, beta, candidati al rilascio, ecc. Quali sono le convenzioni per i numeri di versione inferiori a 1.0? So che possono andare avanti per qualche tempo; ad esempio, PuTTY è in circolazione da almeno un decennio ed è ancora solo alla versione beta 0.60.

Dipende davvero dal progetto; alcuni progetti non rilasciano nemmeno una versione 1.0.

Gli sviluppatori di MAME non intendono rilasciare una versione 1.0 del loro programma di emulazione. L'argomento è che non sarà mai veramente "finito" perché ci saranno sempre più giochi arcade. La versione 0.99 è stata semplicemente seguita dalla versione 0.100 (versione secondaria 100> 99). Allo stesso modo, Xfire 1,99 è stato seguito da 1.100. Dopo 6 anni di sviluppo, eMule non ha ancora raggiunto la versione 0,50. ^{Versione del software su Wikipedia}

Un metodo popolare di numerazione delle versioni (che ho iniziato a utilizzare) è il Semantic Versioning .

In base a questo schema, i numeri di versione e il modo in cui cambiano trasmettono significato sul codice sottostante e su ciò che è stato modificato da una versione all'altra.

Alcune citazioni per darti altre idee su come funziona e / o rispondere ad alcune delle tue domande:

Come faccio a sapere quando rilasciare 1.0.0?

Se il tuo software viene utilizzato in produzione, probabilmente dovrebbe essere già 1.0.0. Se disponi di un'API stabile da cui dipendono gli utenti, dovresti essere 1.0.0. Se ti preoccupi molto della compatibilità con le versioni precedenti, probabilmente dovresti già essere 1.0.0.

Questo non scoraggia il rapido sviluppo e la rapida iterazione?

La versione zero principale riguarda lo sviluppo rapido. Se stai cambiando l'API ogni giorno, dovresti comunque trovarti nella versione 0.xx o in un ramo di sviluppo separato che lavora alla versione principale successiva.

Se anche le più piccole modifiche incompatibili all'indietro dell'API pubblica richiedono un bump della versione principale, non finirò molto rapidamente alla versione 42.0.0?

Questa è una questione di sviluppo responsabile e lungimiranza. Le modifiche incompatibili non dovrebbero essere introdotte leggermente nel software che ha molto codice dipendente. Il costo che deve essere sostenuto per l'aggiornamento può essere significativo. Dover eseguire il bump delle versioni principali per rilasciare modifiche incompatibili significa riflettere sull'impatto delle modifiche e valutare il rapporto costi / benefici.

Ci sono anche regole su come specificare le versioni "alpha", "beta", ecc. Consulta i dettagli su http://semver.org/ .

[Modifica] Un altro schema di numerazione delle versioni interessante è quello che MongoDB usa :

MongoDB utilizza le versioni dispari per le versioni di sviluppo.

Ci sono 3 numeri in una versione MongoDB: ABC

• A è la versione principale. Questo raramente cambierà e significherà cambiamenti molto grandi
• B è il numero di rilascio. Ciò includerà molte modifiche tra cui funzionalità e cose che possono interrompere la compatibilità con le versioni precedenti. Anche i Bs saranno rami stabili, mentre i Bizzarri saranno lo sviluppo.
• C è il numero di revisione e verrà utilizzato per bug e problemi di sicurezza.

Per esempio:

• 1.0.0: prima versione GA
• 1.0.x: bug risolti in 1.0.x - altamente raccomandato per l'aggiornamento, rischio molto basso
• 1.1.x: versione di sviluppo. questo includerà nuove funzionalità che non sono completamente finite e lavori in corso. Alcune cose potrebbero essere diverse da 1.0
• 1.2.x: seconda versione GA. questo sarà il culmine della versione 1.1.x.

Non penso che ci sia uno "standard" in quanto tale.

Esiste una convenzione per i candidati al rilascio che di solito è "[versione] RC 1" ecc. A seconda di quante versioni pensi di poter rilasciare.

Se stai rilasciando una versione molto antica del tuo prodotto - una che non è completa di funzionalità - allora potresti voler andare con la versione "0". In questo modo puoi incrementare la versione nel tempo mentre compili il tuo set di funzionalità.

Userei "Alpha" e "Beta" come Release Candidate - per versioni a tempo limitato per indicare che pensi di essere vicino al rilascio della versione completa.

C'è una pagina di Wikipedia sul controllo delle versioni del software . Per condividere le versioni precedenti alla 1.0, la convenzione utilizzata da Apple e altri funziona bene: major.minor.maintSrev dove S è l'indicatore di fase per le versioni pre-release: d = sviluppo, a = alfa, b = beta, rc = rilascio candidato. Quindi la tua prima versione interna potrebbe essere 1.0.0d1.

Per le revisioni completamente interne, il timestamp è sufficiente.

Ogni sviluppatore decide per lo più quale standard useranno. In generale, tuttavia, i numeri a sinistra del punto decimale indicano grandi revisioni che sarebbero probabilmente molto evidenti per l'utente medio (ovvero modifiche alla funzionalità o all'interfaccia, ecc.). Sul lato destro del punto decimale si tratterebbe di una modifica / modifica / aggiunta che non ha cambiato molto la funzionalità e la progettazione complessive ma ha cambiato qualcosa sul programma stesso (ovvero rendere più veloce una funzione mentre si fa ancora la stessa cosa o si fissa un problema di sicurezza). Quindi, se si aggiungono ulteriori punti decimali, i numeri a destra di questi indicherebbero cambiamenti sempre più piccoli (ovvero correzioni di bug minori / problemi di sicurezza e simili).

Come altri hanno già detto, non sembra esserci uno standard esatto. La nostra organizzazione utilizza la seguente notazione:

Release 1.0 ---> 2.0 (Una funzionalità nuova / migliorata aggiunta al prodotto)

Release 1.0 ---> 1.1 (Una funzionalità nuova / migliorata di livello medio aggiunta al prodotto)

Versione 1.0 ---> 1.001 (correzioni di errori)

La pietra miliare della "versione 1.0" è molto importante per gli utenti di computer esperti, in quanto implica che il programma è fatto e funziona come previsto. Qualsiasi cosa nella versione "0.something" implica che i programmatori stessi pensano che il programma non sia stato ancora fatto .

È possibile mantenere i numeri di versione "0.1", "0.2" ... per le principali realizzazioni della funzionalità e quindi immetterli con un numero di build che spesso è una data e un timestamp sufficientemente precisi.