Ricerca delle migliori pratiche per la numerazione delle versioni dei componenti software dipendenti

Stiamo provando a decidere un buon modo per eseguire la numerazione delle versioni per i componenti software, che dipendono l'uno dall'altro.

Siamo più specifici:

Il componente software A è un firmware in esecuzione su un dispositivo incorporato e il componente B è il rispettivo driver per un normale PC (macchina Linux / Windows). Stanno comunicando tra loro usando un protocollo personalizzato. Dal momento che il nostro prodotto è rivolto anche agli sviluppatori, offriremo versioni stabili e instabili (sperimentali) di entrambi i componenti (il firmware è a codice chiuso, mentre il driver è a codice aperto). La nostra più grande difficoltà è come gestire i cambiamenti API nel protocollo di comunicazione.

Mentre stavamo implementando un controllo di compatibilità nel driver - controlla se la versione del firmware è compatibile con la versione del driver - abbiamo iniziato a discutere di diversi modi di numerazione delle versioni.

Abbiamo trovato una soluzione, ma abbiamo anche voluto reinventare la ruota. Ecco perché mi piacerebbe ricevere un feedback dalla comunità di programmatori / sviluppatori di software, poiché riteniamo che questo sia un problema comune.

Quindi ecco la nostra soluzione:

Abbiamo in programma di seguire la numerazione della versione major.minor.patch ampiamente utilizzata e di utilizzare numeri minori pari / dispari per le versioni stabile / instabile. Se introduciamo modifiche nell'API, aumenteremo il numero minore.

Questa convenzione porterà alla seguente situazione di esempio:

Il ramo stabile corrente è 1.2.1 e instabile è 1.3.7. Ora, una nuova patch per unstable modifica l'API, ciò che farà diventare il nuovo numero di versione unstable 1.5.0. Una volta, il ramo instabile è considerato stabile, diciamo in 1.5.3, lo rilasceremo come 1.4.0.

Sarei felice di una risposta a una delle seguenti domande correlate:

• Puoi suggerire una best practice per la gestione dei problemi sopra descritti?
• Pensi che la nostra convenzione "personalizzata" sia buona?
• Quali modifiche applicheresti alla convenzione descritta?

I numeri di versione di IMHO sono come i nomi dei prodotti; importante in quanto sono visibili ma non importanti in quanto sono decorazioni piuttosto che contenuti.

Tuttavia il numero di versione, come il nome di un prodotto, ha un significato. E la cosa più importante che puoi fare è evitare confusione. Quindi, ecco alcune aspettative comuni rispetto ai numeri di versione. Nella misura in cui queste eccezioni non vengono soddisfatte, l'utente sarà probabilmente confuso:

I numeri di versione sono monotonicamente in aumento
Questa è probabilmente l'aspettativa più ovvia e allo stesso tempo la meno probabile che sia vera. A prima vista, l'utente si aspetta che la versione 2.3.5 sia successiva alla versione 2.2.17 e abbia la stessa o migliore tecnologia. Ma ovviamente 2.3.x è un ramo di sviluppo , e 2.2.x è stabile , e 2.3.5 in realtà è stato rilasciato nel 2004 e il ramo 2.2 è ancora in fase di elaborazione e 2.2.17 è stato rilasciato lo scorso aprile e contiene. .. bene, hai avuto l'idea. Potresti anche chiamare la versione 2.2 "Patata" per tutto il significato che porta il numero. Benvenuti nella versione " Potato-17 " !!

Versioni simili sono aggiornabili / compatibili
Se ho la versione 3.7 sul mio computer e la 3.8 esce con tutti i nuovi frozbot luccicanti, mi aspetto che con qualche aggiornamento o patch o qualsiasi altra cosa, la mia 3.7 possa diventare 3.8 senza interruzioni. Ma se sono su 3.7 e rilasci la 5.2, non sono così ottimista. Certo, preferirei essere piacevolmente sorpreso piuttosto che deluso.

La prima cifra è significativa.
Non mi preoccuperei nemmeno di menzionarlo se Java non fosse così evidentemente confuso sulla questione. A meno che qualcuno non te lo abbia detto, non ti aspetteresti che "Java 7" fosse in realtà la versione 1.7. E la prima volta che hai sentito questo, la tua risposta è stata quasi certamente: " Cosa? .. Perché? "

Chiaramente il purista dirà che il numero di versione principale cambierà solo se la modifica della piattaforma non è compatibile con le versioni precedenti. Ma hai davvero intenzione di abbandonare la retrocompatibilità di sempre ? Spesso i revs delle versioni principali sono una decisione di marketing non tecnica; l'assurdità di Java proviene da entrambi i campi allo stesso tempo, con effetti quasi comici.

Infine,
come ho appena accennato, i numeri di versione spesso riguardano tanto il marketing quanto la tecnologia. E va bene, dal momento che è una specie di numeri di versione: ti informano a colpo d'occhio sulle novità del software. Un grande cambio di numero significa un grande cambio di funzionalità. Una piccola modifica del numero significa quasi nessuna modifica della funzionalità. Questo è ciò che la gente si aspetta . Se è vero o no determina se i tuoi numeri di versione hanno lo stesso significato che gli utenti pensano di fare.

- EDIT -
Ho dimenticato di menzionarlo, ma Caleb lo ha sottolineato bene: non usare i numeri di versione per indicare qualcosa di importante (ad esempio stabile / instabile) senza renderlo altrimenti esplicito altrove. Sì, si sa che il numero di versione minore dispari indica lo sviluppo, ma che ti fa uno di noi. Il moniker di rilascio "instabile" di Debian è un buon esempio; oppure potresti anche usare un nome di prodotto totalmente separato; "Frozbot 1.2" per il nome del prodotto e "Devbot 1.3" per la versione di sviluppo.

Una volta, il ramo instabile è considerato stabile, diciamo in 1.5.3, lo rilasceremo come 1.4.0.

No, no. Per unstable 1.5.3 stable deve iniziare da 1.6.0 (e 1.4.x appena mancato, se si desidera utilizzare Semantic Versioning)

Stai cercando di utilizzare un valore per indicare due cose separate.

Innanzitutto, hai una "versione" che di solito serve per identificare le varie versioni e per indicare l'ordine in cui sono state fatte le versioni. Come ha detto Tylerl, la versione dovrebbe sempre aumentare - non avrebbe alcun senso per gli utenti (e potrebbe anche causare molta confusione interna) se cambi la versione da 1.5.3 a 1.4.0.

In secondo luogo, stai cercando di indicare se una determinata versione è stabile o meno.

È possibile indicare entrambe le cose con un unico "numero di versione", così come alcuni negozi utilizzeranno uno schema di prezzi per indicare se un articolo è in vendita. Ad esempio, i prezzi che terminano con "3" in un negozio vicino a me sono prezzi di vendita finali. Funziona bene per i dipendenti, che imparano rapidamente come individuare un prezzo di vendita, ma non è un ottimo modo per comunicare ai tuoi clienti una vendita. Per questo motivo, hanno anche messo i segni vicino agli articoli in vendita. Potresti fare qualcosa di simile, come rendere uniforme la cifra meno significativa per le versioni stabili e renderla strana per le versioni sperimentali. Penso, tuttavia, che se hai intenzione di rilasciare qualcosa di sperimentale, dovresti contrassegnarlo chiaramente in questo modo. È possibile aggiungere una "X" all'inizio o alla fine della stringa della versione, come:X.1.5.31.5.3.X. Dopo potresti anche un numero di versione sperimentale, quindi puoi rilasciare più versioni sperimentali tutte basate sulla stessa versione di base: 1.5.3.X1, 1.5.3.X2.

Si dovrebbe anche considerare che c'è una lunga tradizione di usare "alpha" e numeri di versione "beta" per indicare le versioni che non possono essere stabili o completa: 1.5.3a54. Assicurati di avere una buona ragione per abbandonare questo schema se decidi di fare qualcos'altro, perché probabilmente dovrai spiegare qualcos'altro alla tua comunità di sviluppatori.

Suggerirei di utilizzare il formato major.minor.patch, usando un "tag" di estensione per le versioni stable / unstable e un significato definito dei numeri maggiori e minori:

major.minor.patch-stable|unstable

dove

major  only changes if there are incompatible changes in the API
minor  changes if there are changes in the API but backward compatibility is given
patch  any other changes, could be the build number or any other increasing number
-stable indicates the stable version
-unstable indicates the unstable version

In questo modo le dipendenze possono essere facilmente gestite e diranno a ciascun componente client / utente quando dovranno prestare maggiore attenzione alle nuove versioni. Ad esempio, se il componente A (1.1.0-stabile) dipende da B (5.4.534-stabile) ed è dovuta una nuova versione di B (6.1.0-instabile) si è immediatamente consapevoli che A dovrà essere cambiato, possibilmente sostanzialmente .

Adoro il modo in cui Hibernating Rhinos ha costruito RavenDb rispetto alle versioni: hanno solo un numero di build sempre crescente. Quando ne ottengono uno stabile viene contrassegnato stabile. Ma tutto è un candidato di rilascio.