Qual è il tuo metodo preferito per nominare le versioni del tuo software?

Question

Qual è il tuo metodo preferito per nominare le versioni del tuo software? Come Microsoft: alpha - beta - final - service pack ... Come Google: gmail beta - beta - beta - beta - :) Come alcuni software: 0,2 - 0,3 - 0,9999 ...

Answer 1

Major.Minor.Release.Build

Mentre gli incrementi di Release e Build non devono contenere " rotture di modifiche " (ad esempio hanno un formato di file diverso per archiviare i documenti), non sono assolutamente sicuro che le versioni minori siano autorizzate.

Il significato dei suffissi alfa e beta è per me:

Alfa / Anteprima: Ehi, ho qualcosa che voglio mostrare.

Beta: finora il set di funzionalità è completo, ma sono rimasti alcuni bug.

Release Candidate: penso che non siano rimasti (maggiori) bug.

Finale: potrebbero esserci ancora dei bug, ma a un certo punto devo rilasciare ;-).

Answer 2

Non rilasciamo software alpha / beta ai nostri clienti. Pertanto utilizziamo semplicemente:

• x.0 (per le versioni principali, contenente importanti / molte nuove funzionalità)
• x.1, x.2, ecc. (per versioni secondarie contenenti nuove funzionalità e miglioramenti minori)
• x.y.1, x.y.2, ecc. (per correzioni di bug / versioni di manutenzione)

(dove x, y = 1,2, ...)

Answer 3

Preferisco il prototipo, il metodo alfa, beta e GA. Ciò mi consente di comunicare agli utenti / clienti lo stato corrente del software. Insieme a ciò fornisco i numeri di versione .2, .3, .4.

• La prima cifra che rappresenta le pietre miliari principali.
• La seconda cifra rappresenta l'incremento del rilascio (generalmente rilascio una volta alla settimana, quindi aumento la seconda cifra).
• La terza cifra viene utilizzata per le patch, quindi se nel codice è presente un bug risolto al di fuori del normale programma di rilascio, utilizzo la terza cifra.

Answer 4

Microsoft utilizza la numerazione delle versioni così come i moniker alpha, beta, GA.

Penso che la denominazione della versione dipenda molto da ciò che stai cercando di realizzare. Se stai rilasciando qualcosa per il consumo e non stai provando a raccogliere dati da un periodo beta, non chiamarlo beta. Se non stai cercando di visualizzare in anteprima la tecnologia, non chiamarla alfa.

Attualmente lavoro principalmente con le app Web e numeriamo le nostre versioni come numeri interi incrementali entro la distribuzione (1, 2, 3, 4, 5, ecc.). Non c'è motivo di dover entrare in complicate logiche di denominazione se a nessuno importa delle versioni.

Answer 5

Per software di piccole dimensioni, solo Major.Minor. Se le modifiche principali - alcuni file di input non sono compatibili con la versione precedente. Non forniamo software di pre-rilascio ai clienti, quindi la stessa versione è destinata ai test e alla versione finale.

Answer 6

Il modo in cui abbiamo dato un nome alle nostre versioni è in genere il numero di fase. Poiché la maggior parte dei nostri contratti sono progetti governativi, lanceremo la prima versione e quindi eseguiremo Fase 2, Fase 3, Fase 4 quando l'entità decide di passare insieme alle nuove richieste di funzionalità (e acquisisce finanziamenti per detti sviluppi futuri).

Answer 7

Alcuni nomi di progetti di software open source vengono rilasciati dopo la data di rilascio. Ad esempio Ubuntu 8.04 è stato rilasciato nell'aprile 2008 e Ubuntu 6.06 è stato rilasciato nel giugno 2006. Ma Ubuntu non è l'unica distribuzione Linux che utilizza questo metodo.

Naturalmente ogni versione di Ubuntu ha anche un nome in codice che è ogni volta un animale diverso, combinato con un aggettivo allitterante (l'aggettivo funge anche da scorciatoia per gli addetti ai lavori). Ogni versione sale in ordine alfabetico in modo che le persone possano ricordare facilmente dove posizionare una versione nel flusso costante. Ad esempio:

Ad esempio 6.06, drapper elegante 6.10, a mezz'aria 7.04, fulvo esuberante 7.10, gibbon gutsy

Answer 8

Preferisco la notazione del kernel Linux: major.minor.release.build, ma uso raramente la parte .build e non uso numeri pari / dispari per minori stabili / di sviluppo.