Nei cicli di rilascio software, la numerazione delle versioni ha raggiunto uno standard de-facto: le “major release” portano un incremento del numero intero, mentre le “minor release” hanno un incremento decimale. Escluse alcune eccezioni (Microsoft che utilizza gli anni o ikernel di Linux) la stragrande maggioranza dei produttori software e anche quelli opensource seguono questo standard. In questo mod, gli utenti possono facilmente capire se una nuova versione è una minor upgrade, comprendente solitamente bug fixes e pochi miglioramenti, o una major, e agiscono di conseguenza.
Negli ultimi anni, VMware ha usato una numerazione per il suo prodotto di punta in un modo completamente differente. Gli ultimi due aggiornamenti da .0 to .1 sono state delle “major”; pensando alle nuove funzionalità e ai maggiori cambiamenti, 4.1 ha cambiato vCenter da 32 a 64 bit, e ultimamente 5.1 ha portato SSO e il Web Client tra le modifiche più visibili (senza considerare quanto è cambiato “sotto pelle”).
Ho sentito numerosi clienti lamentarsi di questo comportamento. Pensavano fossero modifiche minori quindi hanno installato questi aggiornamenti e hanno poi dovuto gestire i cambiamenti. Come sempre, il solito avviso RTFM è necessario anche qui: anche fossero stati aggiornamenti minori, fossero anche singole patch, gli utenti non sono giustificati dal non leggere le note di rilascio. Non di meno, questo approccio non-standard alla numerazione delle versioni da parte di VMware pare stia creando confusione nei clienti.
Se fate caso, è possibile nonostante tutto identificare uno schema nei rilasci di VMware: ogni nuova versione è una “major release”. Pensateci: 3.5 – 4.0 – 4.1 – 5.0 – 5.1. Tutte hanno portato importanti cambiamenti, e possono tutte essere considerate major releases indipendentemente dalla loro numerazione. Correzioni e rilasci minori sono arrivati solo tramite patch e sono state numerate uX (U come Upgrade), come ad esempio 4.1u2.
Ma questo è comprensibile a prima vista da utenti non ben informati? Tutti noi leggiamo i vari blog, forums, partecipiamo a conferenze e webinar. Tutti i clienti fanno lo stesso? O leggono solo le newsletter inviate da VMware o le email inviate dai loro consulenti?
Che ne pensate? Ripeto, è compito dell’utente finali leggere SEMPRE le note di rilascio. Ma forse VMware dovrebbe nonostante tutto migliorare il suo metodo di numerazione?
Il numero di release ha smesso da anni )oserei dire dal secolo scorso) di essere un’indicazione tecnica per diventare parte del brand e, quindi, qualcosa di marketing.
Oramai basarsi su regole presunte della numerazione per valutare la compatibilita’ e’ suicida.
Come detto nel post, nessuna scusa per chi non si è letto prima le release notes.
Ma dissento in parte su quanto dici: per moltissimi produttori e software open source, la numerazione è di fatto un indicatore tecnico, e gli utenti sono stati abituati così.
Questione di lana caprina mi si dirà, ma molte persone su queste cose si sono scottate, e il vendor dovrebbe in ogni caso perlomeno fare in modo di agevolare l’utente nel percepire un minor/major upgrade.
Microsoft ad esempio ha abbandonato del tutto la numerazione e si affida agli anni, mentre Apple addirittura usa i decimali come major releases invece che come minor, però probabilmente ha agito meglio nell’istruire i propri utenti sul significato di quei numeri.
Luca.
sono d’accordo: ogni nuova release annuale, indipendentemente dal numero, ha un contenuto di novità notevole.
Visto che i numeri non costano, potrebbero almeno fare “5.5” invece di “5.1”.
Quanto agli “utenti” è inevitabile: ce ne sono tanti con la foga di avere l’ultima versione quanti che ragionano “finché va non tocco niente”.