Qual è la tua strategia di versioning dell'applicazione? [duplicare]

• How do you keep track of your application's version number? Do you have a formal definition of what each number/character in that version represents?

• What do the different numbers/strings in the application's version mean for your app?

Io uso il seguente:

AppName_<Major>.<Minor>.<Patch/Upgrade>.<BuildNo>

Maggiore : la versione principale è una versione definitiva del prodotto. È aumentato quando ci sono cambiamenti significativi nella funzionalità.

Minore - La versione secondaria viene incrementata quando sono state aggiunte solo nuove funzionalità o correzioni di errori importanti.

Aggiornamento / Patch - L'aggiornamento si riferisce alla sostituzione di un prodotto con una versione più recente del prodotto. Viene incrementato solo quando l'aggiornamento viene fornito sulla versione principale designata. La versione di prova inizia con 0 e incrementa solo quando il bug è stato risolto.

Build No - Il numero di build viene incrementato quando viene creata una nuova build.

• Do you use any automated updating system in your apps (e.g. something like Sparkle) and how good has it been behaving for you?

Utilizziamo lo strumento di costruzione che crea automaticamente app di notte, che chiamiamo build notturne e aumenta il numero di build ogni volta che viene creata una build.

• Do you have a separate update procedure for beta-testers or pre-release testers of your app?

No. I test vengono eseguiti durante la notte di compilazione ogni mattina che chiamiamo BAT (Build Acceptance Test) e verifica la compilazione notturna.

Fammi notare prima non sembra esserci alcun accordo sulla strategia "migliore". Posso solo condividere la mia esperienza su un progetto attuale.

1. La versione del sistema viene definita manualmente in una proprietà build. Succede quando la squadra è d'accordo su una nuova versione. Come versioni aggiuntive utilizziamo il numero di build generato automaticamente dalla build CI

2. Seguiamo genericamente lo schema di denominazione di Ubuntu YY.MM.version.patch_buildNumber poiché abbiamo rilevato che il controllo delle versioni di Major.Minor incasina le aspettative dei clienti;)

3. Non ci sono aggiornamenti automatici in quanto l'applicazione deve essere implementata dagli amministratori

4. Le versioni di test sono più frequenti delle versioni GA, ma dovrebbe essere tutto.

Ho testato molti sistemi di versioni e ora sono abbastanza soddisfatto di questo:

[major].[minor].[revision]

• Maggiore è impostato manualmente e fa riferimento a una versione che include i principali miglioramenti
• Minore è anche impostato manualmente e fa riferimento a una versione di aggiornamento / manutenzione, inclusi miglioramenti e ampli minori; correzioni
• Revisione viene generato automaticamente e fa riferimento a una revisione esatta nel repository.

L'ultimo ci consente di essere molto flessibili con versionning. Possiamo spedire più versioni per più client ed essere ancora in grado di eseguire il debug & risolti facilmente ottenendo la versione specifica dal repository, quindi unisci di nuovo con il trunk.

La build, il packaging e l'amp; la pubblicazione è completamente automatizzata. L'unica azione manuale è quando trasferiamo l'ultimo pacchetto al server di produzione via FTP. Vogliamo mantenere il controllo su ciò per garantire che non consegniamo schifezze in produzione. Va in una fase preliminare in cui i primi utenti possono leggere le note di rilascio e poi decidere di scaricare e utilizzare la versione. I clienti che affrontano bug specifici possono ottenere una versione fissa molto velocemente utilizzando una di queste versioni.

Uso Semantic Versioning per le mie librerie open source e trovo molto più facile lavorare con altre librerie che fanno altrettanto. Fornisce una base comune per capire cosa potrebbe significare un cambio di versione. La libreria è ancora in beta? È una versione solo per correzioni di bug? Ci saranno rotture delle modifiche API?

È fondamentalmente una codifica delle migliori pratiche di versionamento già utilizzate dalla maggior parte dei progetti open source.

Penso che la chiave sia assicurarsi che un rilascio abbia un numero univoco, in modo che tu possa facilmente identificarlo. Il modo in cui quel numero è suddiviso non ha molta importanza. La versione che utilizziamo a cui tengo è major.minor.customerID.buildnumber. Il buildnumber viene generato automaticamente dal nostro script di build.