#Focus: Le build di Windows 10 TP: sviluppo e frequenza

Dopo l’annuncio del programma Windows Insider e la presentazione della nuova versione del sistema operativo di Microsoft, gli animi di tutti noi possessori di Windows Phone si sono eccitati all’idea di poter provare in anteprima Windows 10 per smartphone, nonostante si trattasse di un lavoro in fieri.

Un’eccitazione che non è però durata molto, dopo aver saputo che solo pochissimi modelli (Lumia 830, 730, 630, 635, 636, 638) avrebbero avuto modo di accoppiarsi con la Technical Preview di Windows 10: Microsoft 0, Viagra 1.

Su questo tema ci ha però rassicurati qualche giorno fa Gabriel Aul, che in un twitt assicura che il programma verrà presto esteso ad altri device.

aultwitt

Quali? Non è dato sapere, ma, sinceramente, se per saperlo l’amato Gabe iniziasse di nuovo con i suoi indovinelli come quello sulla data di rilascio della prima build, ne farei anche a meno.

Tuttavia a questo dubbio se ne aggiunge un altro: la cadenza degli aggiornamenti.

L’insider medio si chiede perché, se si tratta di una preview in via di sviluppo dove occorrono grandi quantità di feedback per far progredire il lavoro, il rilascio delle varie build sia così lento.

E perché non si può sapere in anticipo il giorno esatto in cui saranno pubblicate?
La pelata di Gabriel non è mica la sfera di cristallo che fa vedere il futuro, ma qualche risposta può ancora darcela.

Procediamo con ordine.

Cadenza delle build

Innanzitutto bisogna spiegare come si articolano le fasi che portano poi al rilascio delle varie versioni della Technical Preview di Windows 10.

Ring2

In questo schema possiamo vedere chiaramente come esse si articolino in “anelli”:

Canary, il primo, è quello in cui vengono testate le build quotidiane;
OSG, il Gruppo del Sistema Operativo, riceve in test solo le build approvate dal Canary;
– si passa poi all’anello dei dipendenti Microsoft;
– solo le build che hanno passato il test di tutti questi passaggi arrivano agli Insider dell’opzione “Fast“;
– infine tocca agli Insider “Slow“, che ricevono una versione migliorata rispetto al precedente anello.

Il criterio, almeno fino a questo momento, è stato quello della prudenza, anche nei confronti degli Insider che hanno scelto l’opzione “Fast”, tanto che non c’è stata molta distinzione con l’opzione “Slow”.
“Fino a questo momento” perché nei piani alti si sta discutendo se velocizzare o meno i tempi.
Ma (c’è sempre un “ma però”) in realtà build più veloci significherebbero più bug, e questo non è un bene, dato che le anteprime già peccano di stabilità.

È per questo motivo che la cadenza delle varie versioni è di una volta al mese: basti pensare che l’anello “Canary” riceve il doppio/il triplo di build rispetto all’OSG, e che quindi per arrivare anche solo alla fase di test presso i dipendenti Microsoft la scrematura è notevole.

Si tratta comunque di una modalità di procedimento ancora da affinare e suscettibile di modifiche, tanto che si parla di un ulteriore anello denominato “Ludicrous Speed” (tanto veloce da far ridere) per coloro che vogliono ricevere le build con alta frequenza incuranti dei rischi.

D’altro canto ci sono funzionalità che dovranno essere rifinite bene e rese stabili prima di essere mostrate al pubblico e non è possibile prevedere quanto tempo richiederà quest’operazione: a volte sarà veloce altre lenta e da questo, in ultima analisi, dipende la cadenza delle build.

Perché è così difficile stabilire una data entro la quale rilasciare una build?

Avete mai avuto una mole enorme di lavoro da fare, sotto stress e con una data di scadenza precisa?

Ecco, allora si può ben capire come mai a Microsoft abbiano scelto di avere una data aperta e non fissa.
Quindi:

– qualora annunciano una data è perché sanno di poterla rispettare. In caso contrario, creerebbero troppa frustrazione: negli utenti che non vedono rispettata la parola data, e negli stessi ingegneri che perderebbero tempo a darsi colpe e a discutere tra loro invece di procedere col lavoro;

– d’altra parte, se si dovesse improrogabilmente stabilire una data fissa, i dipendenti Microsoft sceglierebbero una data troppo lontana per essere sicuri di rispettarla e di conseguenza se la “prenderebbero comoda”, mentre con una data aperta si cerca sempre di dare tutto se stesso per ultimare il lavoro il prima possibile;
– se la build fosse ultimata prima della data fissata, non verrebbe comunque rilasciata in anticipo proprio per mantenere la parola e rispettarla in ogni caso, positivo o negativo; nel caso contrario, cioè se la build non fosse ultimata in tempo a causa di qualche grave bug, il messaggio che passerebbe al pubblico sarebbe quello di un’azienda non affidabile.

 

Come possiamo vedere, ci sono varie ragioni alla base di qualcosa che a noi potrebbe, dall’esterno, sembrare molto semplice.
Quindi, diamo tempo al tempo e lasciamo che ognuno faccia il lavoro che gli compete: sviluppo gli ingegneri Microsoft e una valangata di feedback gli utenti.

Per concludere, un’ultima curiosità: seppur non ci sia una data certa per il rilascio delle build, aspettiamocele comunque di giovedì, o almeno non di certo di lunedì e venerdì, a Microsoft li evitano!

Fonte Informazioni: Gabriel Aul

Se reputi utile questo contenuto, aiutaci condividendolo!
Articolo precedenteArticolo successivo
Con la passione per la scrittura e maniaco di tecnologia, un esploratore dei recessi della comunicazione e dei suoi mezzi: un Indiana Jones dell'era digitale