Ricerca delle best practice per la numerazione delle versioni dei componenti software dipendenti

I numeri di versione IMHO sono come i nomi dei prodotti; importante in quanto sono visibili ma non importanti in quanto sono una decorazione piuttosto che un contenuto.

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

I numeri di versione aumentano monotonicamente Questa è probabilmente l'aspettativa più ovvia e allo stesso tempo meno probabile che sia effettivamente vera. A colpo d'occhio, l'utente si aspetta che la versione 2.3.5 sia dopo versione 2.2.17 e abbia la stessa o migliore tecnologia. Ma ovviamente 2.3.x è un ramo sviluppo , e 2.2.x è stabile , e il 2.3.5 è stato effettivamente rilasciato nel 2004 e il ramo 2.2 è ancora attivo ha funzionato e 2.2.17 è stato rilasciato lo scorso aprile e contiene ... beh, hai capito. Potresti anche chiamare la versione 2.2 "Potato" per tutto il significato che il numero porta. Benvenuto nella versione " Potato-17 " !!

Versioni simili sono aggiornabili / compatibili Se ho la versione 3.7 sul mio computer e 3.8 esce con tutti i nuovi frozbots lucidi, mi aspetto che con qualche aggiornamento o patch o qualsiasi altra cosa, il mio 3.7 possa diventare 3.8 senza interruzioni. Ma se sono su 3,7 e tu rilascio 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ì prominente in materia. A meno che qualcuno non ti 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 era quasi certamente: " Cosa? .. Perché? "

Chiaramente il purista dirà che il numero di versione principale cambierà solo se il cambio di piattaforma non è retrocompatibile. Ma hai intenzione di abbandonare la compatibilità mai ? Spesso i rev di versione maggiore sono una decisione di marketing non tecnica; l'assurdità di Java proviene da entrambi i campi facendosi allo stesso tempo, a un effetto quasi comico.

Infine
Come ho appena detto, i numeri di versione sono spesso tanto sul marketing quanto sulla tecnologia. E va bene, dato che questo è il tipo di versione dei numeri: ti informano a colpo d'occhio sulle novità del software. Un grande cambiamento di numero significa grandi cambiamenti di funzionalità. Il piccolo cambiamento di numero significa quasi nessun cambiamento di funzionalità. Questo è ciò che le persone si aspettano . Che sia vero o no determina se i tuoi numeri di versione hanno lo stesso significato che i tuoi utenti pensano di fare.

- EDIT - Ho dimenticato di dirlo, ma Caleb me lo ha fatto notare: non utilizzare i numeri di versione per indicare qualcosa di importante ( ad esempio stabile / instabile) senza renderlo altrimenti esplicito altrove. Sì, tu sai che il numero di versione minore dispari indica lo sviluppo, ma questo è uno di noi. Il moniker di rilascio "unstable" di Debian è un buon esempio; oppure potresti anche usare un nome di prodotto completamente separato; "Frozbot 1.2" per il nome del tuo prodotto e "Devbot 1.3" per la tua versione di sviluppo.

Once, the unstable branch is considered stable, let's say in 1.5.3, we will release it as 1.4.0.

No-no. Per unstable 1.5.3 stable deve iniziare da 1.6.0 (e 1.4.x appena perso, se non vuoi usare il Semantic Versioning)

Stai tentando di utilizzare un valore per indicare due elementi distinti.

In primo luogo, 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 diceva tylerl, la versione dovrebbe sempre aumentare - non ha alcun senso per gli utenti (e potrebbe causare anche molta confusione interna) se si cambia la versione dalla 1.5.3 alla 1.4.0.

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

È possibile possibile indicare entrambe le cose con un solo "numero di versione", proprio come alcuni negozi utilizzeranno alcuni schemi di prezzo per indicare se un articolo è in vendita. Ad esempio, i prezzi che terminano in "3" in un negozio vicino a me sono prezzi finali di vendita. Ciò funziona bene per i dipendenti, che imparano rapidamente come individuare un prezzo di vendita, ma non è un ottimo modo per dire ai tuoi clienti di una vendita. Per questo motivo, hanno anche messo dei cartelli vicino agli articoli in vendita. Potresti fare qualcosa di simile, come fare la cifra meno significativa per le versioni stabili anche e renderla strana per le versioni sperimentali. Penso, però, che se rilascerai qualcosa di sperimentale, dovresti contrassegnarlo chiaramente in questo modo. Puoi aggiungere una "X" all'inizio o alla fine della stringa della versione, ad esempio X.1.5.3 o 1.5.3.X . Potresti anche avere un numero di versione sperimentale, quindi potresti rilasciare più versioni sperimentali tutte basate sulla stessa versione di base: 1.5.3.X1 , 1.5.3.X2 .

Dovresti anche considerare che esiste una lunga tradizione nell'uso dei numeri di versione "alpha" e "beta" per indicare versioni che potrebbero non essere stabili o complete: 1.5.3a54 . Assicurati di avere una buona ragione per uscire da questo schema se decidi di fare qualcos'altro, perché probabilmente dovrai spiegare qualsiasi altra cosa alla tua comunità di sviluppatori.

Suggerirei di utilizzare il formato major.minor.patch, utilizzando un'estensione "tag" per versioni stabili / instabili e un significato definito dei numeri maggiore e minore:

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 sono facilmente gestibili e diranno a ogni componente client / utente quando devono prestare maggiore attenzione alle nuove versioni. Per esempio. se il componente A (1.1.0-stabile) dipende da B (5.4.534-stabile) e una nuova versione di B è dovuta (6.1.0-instabile), uno è immediatamente consapevole che A dovrà essere cambiato, possibilmente sostanzialmente.

Adoro il modo in cui Hibernating Rhinos ha creato le versioni RavenDb di fronte - hanno un numero di build sempre crescente. Quando ne ottengono uno stabile viene contrassegnato come stabile. Ma tutto è un candidato alla release.