L'open source ora si trova al centro del software commerciale, non ai margini. Una sintesi del 2024 di Synopsys e Open Source Security and Risk Analysis ha trovato che 96% di codici commerciali contenevano software open source, e 77% di cui il code nei codici di quei progetti era open source, mentre lo studio della Linux Foundation del 2022 stimava che il contenuto open source fosse di circa 70% a 90% di un codice di un software (la panoramica di Intel sull'uso di open source). Se il tuo prodotto viene spedito su telefoni, desktop o dispositivi, un aggiornatore open source non è un feature di comodità. È parte del sistema di consegna che mantiene quelle dipendenze, bundle e asset di runtime al sicuro per essere eseguiti in produzione.
Questo conta perché il traffico degli aggiornamenti non è più piccolo o occasionale. NetApp Instaclustr ha riferito che il npm ha gestito 4,5 miliardi di richieste di download nel 2024, PyPI ha raggiunto 530 miliardi di download, Maven Central ha elaborato 1,5 trilioni di download, e NuGet gestiti 159 miliardi di richieste in lo stesso anno, con ecosistemi che servono più di 6,6 trilioni di pacchetti dal 2019 (Statistiche del software open source di InstaclustrContenuto del documento
La tabella dei contenuti
- Perché gli aggiornatori open source sono importanti nel software moderno
- How Funziona un Aggiornatore Open Source sotto la Cappa
- Perché sopravvivere agli aggiornamenti dannosi è più importante di ottenerli
- Aggiornatore Open Source Auto-Hostato contro Servizio di Aggiornamento Gestito
- Integrazione di un aggiornatore in Capacitor e applicazioni Electron
- Observabilità e risoluzione dei problemi per gli aggiornamenti in tempo reale
- Scegliere la strategia di aggiornamento giusta per il tuo team
Perché gli aggiornatori open source siano importanti nel software moderno
Un aggiornatore open source è la macchina client-side che controlla la presenza di una versione più recente, scarica le modifiche, le verifica e le applica senza forzare una rilascio completo del magazzino o una reinstallazione manuale. In pratica, ciò può significare un plugin Capacitor che invia nuovi asset web a un'app mobile, un aggiornatore di Electron che sostituisce i pacchetti desktop, o un piccolo agente che aggiorna la configurazione su un dispositivo embedded. La forma cambia a seconda della piattaforma, ma il compito rimane lo stesso, spostare code affidabili dal server al dispositivo con il minimo attrito possibile.
Perché il problema è più grande di quanto sembri
Molti team incontrano per la prima volta gli strumenti di aggiornamento come richiesta di funzionalità del prodotto. Un cliente richiede un hotfix più veloce, un team di supporto vuole meno reinstallazioni, o una rilascio mobile richiede un modo per bypassare i ritardi di revisione del negozio. Questa prospettiva è troppo piccola. Una volta che il tuo'app dipende dai pacchetti open source, l'aggiornatore diventa un punto di controllo per la freschezza, la sicurezza del rollback e la fiducia di code.
La scala dietro a questo spostamento è già visibile nella catena di fornitura. Se i pacchetti si muovono a un volume di richieste di un trilione, un percorso di aggiornamento cattivo non colpisce solo un installazione, ma si moltiplica attraverso i canali, le regioni e i treni di rilascio. L'aggiornatore si trova davanti a tutto ciò. È la porta finale prima che code raggiunga gli utenti finali, e ogni controllo aggiuntivo, firma e percorso di fallback deve guadagnare il suo posto.
A un buon modello mentale è trattare la logica dell'aggiornamento come lavoro di hosting e manutenzione, non come un plugin che si aggiunge alla fine. Quanto più il tuo app è critica per le release, tanto più il tuo aggiornamento assomiglia a parte delle operazioni. Un'overview pratica di quel mindset è descritta nel 2026 guida di hosting e manutenzione, che è utile perché la stessa disciplina si applica qui, il patching, la verifica e il rollback sono preoccupazioni operative, non solo dettagli ingegneristici.
Cosa fa effettivamente l'aggiornamento
Un aggiornamento affidabile esegue di solito quattro compiti. Esso controlla una fonte remota per il canale o la versione giusta, scarica solo ciò che serve, verifica che il payload è autentico, e applica il risultato in un modo che non lascia l'applicazione rotta in volo. Se alcune di quelle fasi sono deboli, l'intera esperienza si sente poco affidabile anche quando il livello di trasporto è veloce.
Quello è il motivo per cui la distinzione tra “può aggiornare” e “può aggiornare in modo sicuro” conta così tanto. Le squadre spesso iniziano cercando una libreria che renda la distribuzione più facile, poi scoprono che il problema più difficile è la fiducia, la distribuzione in fasi, e la ripresa. Per le Capacitor squadre, un punto di partenza utile è l'ecosistema intorno al modello di aggiornamento open-source descritto in Capgo’s Capacitor guida per l'aggiornamentoperché mostra come la consegna client-side diventa parte delle meccaniche di rilascio dell'applicazione.
Dove questi strumenti si presentano
Si vede il pattern nelle app mobili costruite con Capacitor, strumenti desktop costruiti con Electron, e anche software di dispositivi specializzati dove l'app non può dipendere da un flusso di lavoro di tipo store. In ogni caso, l'aggiornatore è un ponte tra il controllo di rilascio server-side e l'esecuzione client-side. Quel ponte deve essere stretto, esplicito, e facile da verificare.
Per un ingegnere mobile senior, la domanda pratica è semplice. Questo aggiornatore può consegnare un bundle, provare che è valido, e tornare indietro pulitamente se il bundle è sbagliato? Se la risposta è vaga, lo strumento è ancora un prototipo.
Come funziona un Aggiornatore Open Source sotto la cappa
Un aggiornatore di produzione separa metadati dal blob di datiLa prima richiesta del client è un manifesto compatto che dice quale versione è disponibile, cosa è cambiato e cosa il dispositivo dovrebbe aspettarsi. Solo dopo di ciò scarica il payload stesso, o il delta tra bundle di origine e di destinazione, il che è come molti sistemi tengono le trasferimenti più piccoli di un reinstall completo (La progettazione di Android's update_engine).
La strada di aggiornamento da controllo a applicazione
Di solito inizia con un controllo della versione. L'app invia un ping a un endpoint remoto, spesso all'avvio o alla ripresa, e chiede se esiste una versione più recente del suo canale corrente. La risposta del server rimane intenzionalmente piccola, perché il client ha bisogno solo di abbastanza dati per decidere se continuare.
La prossima è la comparazione del manifesto. Il manifesto dice al client quali file, hash o identificatori di bundle dovrebbero esistere nella versione di destinazione. Quella comparazione è il punto in cui l'aggiornatore decide se ha bisogno di un payload completo o di un set di delta più piccolo. Un aggiornatore ben progettato si comporta più come un fetch di oggetti Git che come un download di archivio completo, perché solo il contenuto modificato dovrebbe essere trasferito via cavo.
Dopo di ciò, il client scarica il blob di dati . In sistemi basati su bundle, ciò potrebbe essere un pacchetto di asset web o un archivio compresso. In sistemi basati su file, ciò potrebbe essere un insieme di artefatti modificati che vengono assemblati localmente. In ogni caso, la parte importante è che il client non si fida di byte solo perché sono arrivati.
Infine, l'aggiornatore esegue un' applicazione atomica. La nuova versione è messa in scena, validata e sostituita in un passo controllato invece di sostituire file in esecuzione pezzo per pezzo. L'applicazione atomica riduce la possibilità di un installazione a metà, che è l'equivalente di un'aggiornamento di migrazione del database parziale.
Regola pratica: se l'aggiornatore non può spiegare cosa è cambiato prima di scaricare, probabilmente stai inviando un payload completo più spesso del necessario.
Perché i payload di differenza sono importanti
Il payload di differenza è la parte che molti team sottovalutano. Fanno più che risparmiare banda, riducono l'esposizione durante il rollout perché il client gestisce solo la superficie di cambiamento. Ciò conta nelle reti mobili, nei dispositivi con restrizioni e in qualsiasi punto un riavvio o un trasferimento fallito è costoso.
Il manifesto vi dà anche spazio per la politica. Potete decidere se un build è eleggibile per un flusso beta, un rollout di produzione in fase di staging o una rilascio specifico per i clienti. In un flusso di lavoro Capacitor, il controllo del canale si mappa pulitamente alla spedizione di bundle web senza dover tornare ogni volta attraverso la store dell'app. a practical reference for Capacitor live-update workflows.
un riferimento pratico per i flussi di aggiornamento live di __CAPGO_KEEP_0__
La sincronizzazione non può affidarsi solo alla sicurezza dei trasporti. Ha bisogno di controlli di integrità sul manifesto e sul payload, quindi un modello di applicazione che eviti di corrompere l'installazione live. È per questo che i sistemi maturi separano la “decisione di cosa cambiare” dalla “scrivere byte” passo. La separazione offre un luogo per verificare prima di modificare qualcosa.
Quando gli squadre saltano quella separazione, costruiscono spesso percorsi di aggiornamento fragili che sono difficili da debug e ancora più difficili da ripristinare. I sistemi migliori trattano la verifica come parte della pipeline di applicazione, non come un extra estetico.
Perché sopravvivere agli aggiornamenti dannosi è più importante del loro recupero.
Mettere i byte sui dispositivi è routine. Il problema più difficile è mantenere la produzione stabile quando un nuovo pacchetto esporre un bug, una disallineamento di configurazione o un'assunzione rotta nell'ambiente live.
Endor Labs ha riferito che 95% degli aggiornamenti di versione open-source contengono almeno un cambiamento dirottantee anche le patch hanno una 75% probabilità di causare un break (La copertura di Infosecurity Magazine della ricerca di Endor Labs. Questo cambia la mia valutazione di un sincronizzatore nella pratica. Mi importa meno di sapere se può scaricare una versione e più di sapere se può assorbire la falla senza costringere gli utenti a un build funzionante.
La rollback non è facoltativa
Un sincronizzatore serio ha bisogno di un percorso di rollback chiaro. wyUpdate documenta la rollback in caso di errore irreversibile o annullamento dell'utente, e TUF è stato costruito per aggiungere fiducia stratificata e verifica contro compromissione del repository o della chiave di firma (wyUpdate e TUF di riferimentoEssi risolvono parti diverse del problema, ma la lezione si allinea, la ripristino deve essere parte del design fin dall'inizio.
In ambito mobile, ho visto bundle cattivi partire perché il code era compilato, gli asset erano firmati e il dispositivo di test era passato. La falla si manifestava solo quando un piccolo subset di dispositivi colpiva un caso di confine nello stato di runtime. Se l'aggiornatore non può ripristinare automaticamente la versione precedente funzionante, il carico di supporto cresce rapidamente e il rilascio diventa una responsabilità.
La rollback dovrebbe essere noioso. Se gli operatori hanno bisogno di un playbook di recupero manuale ogni volta che un bundle si comporta male, il processo di rilascio è già troppo fragile.
La verifica dell'integrità protegge la via di rilascio
Le verifiche dell'integrità fanno più che bloccare payload malintenzionati. Catturano anche la corruzione, gli artefatti di canale sbagliato e gli errori di pubblicazione accidentali prima che l'app scriva qualcosa di permanente. Ciò conta negli ambienti regolamentati, dove un rilascio fallito può creare un impatto sui clienti e problemi di audit allo stesso tempo.
La progettazione di un aggiornatore sicuro e il controllo di rilascio operativo si incontrano nella verifica. Se il tuo aggiornatore controlla firme, verifica manifesti e rifiuta di applicare qualcosa ambiguo, riduci un gran numero di rischi a livello basso. La verifica da sola non limita il raggio d'azione di un'esplosione, tuttavia. La distribuzione in fasi ancora conta.
La distribuzione in fasi limita il danno
La fase di staging ti consente di pubblicare un aggiornamento a un pubblico ristretto per prima, osservare il comportamento e poi allargare la rilascio solo se i dati di telemetria rimangono puliti. Questo controllo è particolarmente prezioso per le app di fronte ai clienti, dove un rilascio veloce è utile solo se non costringe a un rollback pochi minuti dopo.
Per me, lo spostamento dell'evaluazione è semplice. Un aggiornatore sicuro non è quello che aggiorna più velocemente. È quello che rende le rilasci dannosi piccoli, visibili e reversibili.
Aggiornatore Open Source Auto-Hostato Versus Servizio di Aggiornamento Gestito
L'aggiornatore auto-hostato è adatto a team che desiderano avere il controllo diretto sulle chiavi di firma, sui manifesti, sulle regole di distribuzione e sulla conservazione dei dati. I servizi di aggiornamento gestiti sono adatti a team che desiderano meno infrastruttura da gestire e più regole operative integrate. Entrambi possono funzionare. La scelta sbagliata è spesso quella che ignora il carico del giorno due.
Un approccio ibrido è comune nella pratica, dove il plugin del client è open source ma la livella di consegna e la politica sono gestite. Questo schema consente ai team di avere un controllo significativo senza costringerli a gestire ogni pezzo della pipeline di rilascio. Un esempio utile di come i team pensano a questo trade-off è la discussione sugli aggiornamenti live auto-hostati.
Confronto tra Aggiornatore Auto-Hostato e Aggiornamento Gestito
| Dimensione | Aggiornatore Open Source Auto-Hostato | Servizio di Aggiornamento Gestito |
|---|---|---|
| Carico di infrastruttura | La tua squadra gestisce lo storage, la consegna, la firma, il monitoraggio e la ripristino | La fornitore possiede la maggior parte della tubatura di consegna |
| Modello di sicurezza | Controllo totale, ma anche la piena responsabilità delle chiavi e della politica di fiducia | Controlli di sicurezza centralizzati con confini definiti dal fornitore |
| Osservabilità | Può essere molto profondo se lo costruisci bene, ma devi costruirlo | Solitamente costruito in, con visibilità a livello di dispositivo e storia delle versioni |
| Controllo di distribuzione | Personalizzabile in modo molto dettagliato se mantieni l'engine di politica | Di solito più facile da gestire all'interno di canali e cohort |
| Compatibilità con le normative | Fortificato se il tuo team ha bisogno di un controllo interno esplicito | Se le controlli del fornitore sono allineati alle tue esigenze di audit |
Come valutare il costo totale
Il self-hosted sembra più economico sulla carta perché il software stesso può essere open source. In pratica, tuttavia, hai ancora bisogno di infrastruttura di firma, distribuzione CDN, automazione di distribuzione, osservabilità e un modo per gestire il rollback quando qualcosa va storto. Quello è un grande spazio operativo per un piccolo team.
Il servizio gestito assorbe gran parte di quel carico, ma aggiunge una relazione con il fornitore e un insieme di vincoli del prodotto. Per un team che sta inviando applicazioni regolate o faccia a faccia con i clienti, quel trade-off può essere valutato se il servizio ti dà i log, il controllo del canale e il comportamento di recupero che ti serve. Per un team di piattaforma con strumenti interni forti, il self-hosted può essere la scelta giusta perché mantiene il percorso di rilascio all'interno del tuo piano di controllo.
Cosa decide di solito la scelta
Il costo è solo un fattore. La proprietà del percorso di rilascio è di solito il fattore decisivo. Se il tuo aggiornatore deve sopravvivere agli audit, alle escalazioni del supporto e alle finestre di rollback strette, il costo totale di proprietà è dove la risposta si manifesta.
L'integrazione di un aggiornatore in Capacitor e applicazioni Electron
On our team, the first time updater tooling came up was when a support lead asked for emergency hotfixes during a holiday window. That kind of request changes the conversation fast. Capacitor and Electron solve similar delivery problems in different runtime shapes, so the updater should fit the platform instead of forcing one release pattern everywhere. In Capacitor, the updater is usually tied to web bundle delivery and app lifecycle events. In Electron, the updater follows the desktop app’s code signing and restart model much more strictly.
Se si sta spostando da strumenti di aggiornamento in tempo reale più vecchi, si dovrebbe aspettarsi che la configurazione cambi più della mentalità. L'applicazione ha ancora bisogno di un canale di rilascio, una fonte di pacchetti e un punto di decisione per quando applicare un aggiornamento. La differenza pratica è nella pipeline di rilascio. È necessario eseguire controlli di firma prima della pubblicazione, una mappatura chiara dall'artefatto di costruzione al canale e un percorso di riavvio che si comporta in modo prevedibile alla prossima avviatura. Per i modelli di aggiornamento specifici di Electron, le note di aggiornamento di Electron sono un punto di riferimento pratico.
Capacitor integrazioni di pattern
Per Capacitor, il primo compito è installare il plugin di aggiornamento, puntarlo all'endpoint di aggiornamento e decidere quale canale utilizzare per ogni build. Beta, staging e production dovrebbero essere espliciti, perché gli errori di canale sono uno dei modi più facili per inviare il pacchetto sbagliato agli utenti sbagliati. Ho visto team trattare la canalizzazione come un compito di pulizia successivo e che di solito finisce con un rollback confuso.
Il passo successivo è la connessione della verifica dell'aggiornamento agli eventi di ciclo di vita dell'applicazione. Lancio e ripresa sono le pale azzurre, perché gli utenti attraversano naturalmente quei confini. Alcune squadre aggiungono anche un timer, ma ciò funziona solo se il modello di stato dell'applicazione può tollerare controlli in background senza creare ritentativi rumorosi o download non necessari. Un controllo in background che si attiva mentre l'applicazione è già in fase di ripresa può attivare fetch duplicati, quindi il modello più sicuro è scegliere un trigger per ogni transizione di stato e mantenere il comportamento di ritentativo esplicito.
La tua pipeline di costruzione dovrebbe pacchettizzare il bundle web, firmare l'artefatto dove richiesto, pubblicarlo sul servizio di aggiornamento e registrare quale canale lo ha ricevuto. Dovrebbe anche timbrare la costruzione con l'identificatore di commit o rilascio che ha prodotto il bundle, in modo che il supporto possa tracciare cosa è stato spedito senza dover scavare nei log. Se lo step di pubblicazione è manuale, il drift compare velocemente, di solito come una costruzione che esiste nel CI ma non raggiunge mai il canale dell'applicazione che sta controllando.
Modelli di integrazione di Electron
Il flusso di aggiornamento di Electron è più opinativo. L'applicazione controlla, scarica e poi applica gli aggiornamenti in un percorso orientato al riavvio, che si adatta meglio al software desktop rispetto al patching in background. Ciò significa che il tuo setup di firma code deve essere solido prima della prima rilascio, perché le catene di fiducia desktop sono meno perdonanti delle scambi di asset web.
Per le squadre che stanno migrando da strumenti più vecchi, il cambiamento più grande è solitamente nella quantità di metadati di rilascio che conservano. Potreste perdere alcune comodità se l'antico sistema nascondeva la complessità del canale dietro un singolo API, ma guadagnate un controllo più chiaro sulla provenienza del pacchetto e sul comportamento di rollback. Questo trade-off vale la pena per le squadre che inviano aggiornamenti desktop frequenti, perché quando un problema si verifica, avete bisogno di sapere esattamente quale binario è stato offerto, quale è stato accettato e se l'utente ha riavviato in esso.
La migrazione più pulita è quella che tratta la consegna degli aggiornamenti come un problema di artefatto di costruzione, non come un problema di logica dell'applicazione.
Cosa collegare alla CI
Un pipeline affidabile solitamente fa tre cose. Costruisce il pacchetto, firma l'artefatto e pubblica sul canale corretto. Dopo di che, dovrebbe emettere metadati di rilascio che le squadre di supporto possono utilizzare per tracciare quale costruzione è stata offerta a quale cohort, e un puntatore di rollback che vi consente di fermare l'esposizione se il nuovo pacchetto inizia a fallire.
Un pipeline di rilascio che non può rispondere a quelle domande è troppo vago per gli aggiornamenti in tempo reale. L'applicazione potrebbe ancora installarsi, ma nessuno avrà fiducia nel processo quando la prima incidente si verifica.
Osservabilità e Risoluzione dei Problemi per Aggiornamenti in Tempo Reale
Aggiornamenti che falliscono in modi ordinari. I dispositivi sono offline, i manifest non corrispondono alla versione installata, le verifiche di firma falliscono dopo una rotazione della chiave, o un utente è bloccato su un vecchio pacchetto perché non ha completato un ciclo di riavvio completo. Non è necessario avere una perfetta telemetria per iniziare, ma è necessario avere una sufficiente visibilità per spiegare cosa è successo su un dispositivo specifico.
Una buona osservabilità degli aggiornamenti è la stessa mentalità di una buona osservabilità dell'applicazione, solo puntata verso il flusso di rilascio. Il guida all'osservabilità dell'applicazione è utile perché pone il percorso di rilascio come qualcosa che puoi ispezionare, non solo qualcosa che spera di funzionare.
Quello che registrare
Vorresti registri per dispositivo mostrando quale versione è stata offerta, scaricata, verificata e applicata. Vorresti anche tracciare l'adozione per vedere se una versione sta passando attraverso la tua base di utenti, più registri di fallimento per errori di download, fallimenti di verifica e trigger di rollback. La storia delle versioni è anche importante, perché il supporto deve sapere quale versione sta utilizzando l'utente prima di chiedergli di riprovare.
Quei registri non devono essere rumorosi. Devono essere precisi. Un registro di aggiornamento pulito dovrebbe permetterti di rispondere a quattro domande velocemente, cosa il dispositivo ha chiesto, cosa il server ha offerto, se la verifica è passata e se l'applicazione finale è riuscita.
Modi comuni di fallimento
A un utente bloccato su una versione vecchia significa che il flusso di aggiornamento non è mai stato portato a uno stato di applicazione riuscito. In pratica, ciò può essere un problema di riavvio, una disallineamento del canale o un problema di rete che ha mantenuto il manifesto aggiornato ma non ha mai consegnato il payload. Un utente produttivo che riceve una versione beta indica un errore di mappatura del canale o un passaggio di pubblicazione che ha mirato alla cohorte sbagliata.
Il disallineamento di firma si manifesta spesso dopo una rotazione di chiave o un processo di pubblicazione che ha firmato l'artefatto sbagliato. Quando ciò accade, la prima cosa da verificare non è il client. È il registro di rilascio del server e la pipeline di firma.
Se il supporto non può vedere la versione offerta e la versione applicata fianco a fianco, il debugging richiederà più tempo del dovuto.
La rete di sicurezza minima
Almeno, costruisci un dashboard che mostra la distribuzione delle versioni, i conti di fallimento e gli eventi di rollback. Assicurati poi che il supporto possa cercare un dispositivo per identificatore o account cliente e vedere il percorso di rilascio associato. Ciò non prevenirà ogni problema, ma trasformerà un lamento di aggiornamento vago in qualcosa di azionabile.
La scelta della strategia di aggiornamento giusta per il tuo team
I sviluppatori solitari desiderano spesso una consegna con basso impatto operativo e il minimo di macchinari di rilascio che possano ottenere. Per quel profilo, un aggiornatore gestito o ibrido è spesso più facile da mantenere rispetto a una pila di hosting completamente autonoma. Le piccole squadre che distribuiscono applicazioni cross-platform spesso hanno bisogno di rilasci in fasi e di controllo dei canali, quindi un modello ibrido con un client open source e un backend gestito tende a funzionare bene.
Le squadre mobili aziendali in settori regolamentati dovrebbero iniziare con l'auditabilità, il controllo del rollback e le barriere di approvazione. Possono utilizzare strumenti open source di hosting autoamministrato se sono pronte a gestire la layer di piattaforma, ma molti preferiranno un sistema gestito che offre loro una visibilità operativa più forte senza dover costruire ogni primitivo di rilascio da zero. Le agenzie che gestiscono molte applicazioni dei clienti hanno bisogno di controllo multi-tenant e separazione chiara tra i clienti, il che li porta spesso verso un setup gestito o ibrido.
Se non puoi rispondere a queste tre domande, non scegli ancora un modello di consegna. Puoi annullare senza distribuire una nuova versione dell'archivio dell'applicazione, puoi vedere cosa è successo su ogni dispositivo e puoi tenere il canale sbagliato fuori dagli utenti di produzione? Se qualsiasi di questi è no, la scelta più sicura è quella che ti dà quei controlli con il minimo di macchinari aggiuntivi.
Inizia con la fase di staging, non con la velocità. Il primo rilascio dovrebbe dimostrare la tua rete di sicurezza, non la tua ambizione.
Una rappresentazione grafica delle tre strategie di aggiornamento software per gli sviluppatori etichettate come Solo/Indie, Small Team e Enterprise con icone.
A un passo successivo è semplice. Verifica il tuo percorso di aggiornamento attuale, testa il rollback prima di averne bisogno e pubblica un rilascio di staging controllato prima di ampliare l'accesso. Se stai cercando una piattaforma di aggiornamento live costruita per Capacitor e Electron con controllo di canale, comportamento di rollback, registrazioni per dispositivo e pubblicazione amichevole per CI, visita Capgo e valutalo rispetto ai rischi di rilascio che porti.
