Guida alle note di versione
Release di Citron: note di versione e guida ai build
Usa le pagine GitHub ufficiali per identificare un tag stabile, leggere le modifiche, scegliere il file corretto e conservare un punto di ritorno.
Cosa controllare in una release di Citron
Le release di Citron sono divise tra un tag datato nel repository citron-neo/emulator e build di piattaforma che avanzano in citron-neo/CI. La pagina stabile mostra attualmente il tag 2026-04-27. Una pagina CI può pubblicare un commit upstream più recente senza cambiare il tag stabile: salva quindi repository, tag o commit, piattaforma e data di pubblicazione.
La descrizione ufficiale spiega cosa è cambiato e cosa può essere stato spostato. Leggila prima di sostituire un build funzionante: una correzione del renderer, l'invalidazione della cache, una modifica della configurazione o una regressione di piattaforma cambia la scelta corretta. Il titolo da solo non è una prova.
Il 23 ottobre 2026 le pagine ufficiali mostravano un build CI Linux basato sul commit 598b700 e datato 16 ottobre. È un esempio legato a una data, non una promessa per ogni piattaforma. I canali CI avanzano separatamente: riapri la pagina della piattaforma prima di installare.
Mappa delle versioni attuali
Release di Citron verificate il 23 ottobre 2026
Queste identità spiegano lo scopo delle pagine. Le date sono verifiche puntuali e vanno ricontrollate prima dell'installazione.
Tag stabile: 2026-04-27
Il tag con data è la base migliore per un test ripetibile. Cambia meno di un canale CI e offre un punto di ripristino chiaro.
Fonte: github.com/citron-neo/emulator/releasesI build CI usano commit upstream
Il repository CI pubblica build per Windows, Linux, macOS e Android. Un commit breve è più utile di un generico latest.
Fonte: github.com/citron-neo/CI/releasesEsempio CI Linux: 598b700
La release Linux consultata indicava il commit 598b700 e la data 2026-10-16. Controlla di nuovo il tag corrente.
Pagina CI ufficiale verificata il 23/10/2026Le note non sono file di gioco
Una release GitHub contiene file e note del progetto, non giochi protetti, file privati della console o chiavi.
Separa i file dell'emulatore dai tuoi file legali
Leggi l'identità prima del changelog
Una piccola registrazione evita di considerare ogni tag mobile come la stessa versione. Salva prima l'identità, poi interpreta le note.
| Canale | Identità da salvare | Cosa indicano le note | Azione pratica |
|---|---|---|---|
| Stable | Tag 2026-04-27 | Note e file datati | Usare come base |
| CI Linux | 598b700, 16/10/2026 | Commit upstream e formati | Testare se serve la correzione |
| CI Windows, Android, macOS | Tag e commit della piattaforma | Stato specifico del sistema | Verificare ogni pagina |
| Archivio sorgente | ZIP generato da GitHub | Snapshot per sviluppatori | Non usarlo come installer |
La pagina ufficiale della release è la destinazione del download. Evita CDN indovinate, link brevi, installer repackati e mirror senza contesto.
Leggere le note
Quattro segnali nelle note di versione Citron
Le note sono utili quando rispondono a una decisione concreta. Cerca questi segnali prima di scaricare un aggiornamento.
Ambito di compatibilità o regressione
Cerca riferimenti a gioco, renderer, controller, sistema operativo o firmware. Una correzione locale non vale automaticamente per ogni piattaforma.
- Segna il sottosistema o la piattaforma.
- Distingui fixed, changed, experimental e known issue.
- Conserva il build attuale se la nota non riguarda il problema.
Modifiche a configurazione e cache
Una versione può invalidare la shader cache, spostare la cartella utente, cambiare i valori predefiniti o chiedere un primo avvio pulito.
- Fai un backup della configurazione.
- Non copiare una cache vecchia senza motivo.
- Segui la migrazione descritta nella nota.
Indizi su file e architettura
I nomi possono distinguere x64, x86_64_v3, aarch64, Android o macOS. Scegli il pacchetto adatto al dispositivo.
- Conferma sistema e architettura.
- Tratta AppImage, ZIP, DMG e APK come formati diversi.
- Leggi la descrizione se il suffisso è insolito.
Indizi per il rollback
Commit, data e note rendono concreto un rapporto di regressione. Salvali prima del test.
- Tieni il build precedente.
- Annota scenario e impostazioni.
- Comunica l'identità, non solo latest.
Scegli un asset di piattaforma senza indovinare
Le note spiegano la modifica e la lista degli asset mostra cosa può funzionare sul dispositivo. Usa entrambe.
Conferma il proprietario
L'indirizzo deve essere sotto github.com/citron-neo/ e corrispondere al repository previsto.
Copia tag o commit
Salva il tag stabile o il commit completo mostrato nella descrizione prima del download.
Abbina il sistema
ZIP Windows, AppImage/tar.zst Linux, DMG macOS e APK Android sono formati diversi.
Abbina l'architettura
Scegli x86_64, x86_64_v3, aarch64 o Apple silicon solo se corrisponde al dispositivo.
Mantieni il contesto
Scarica dalla lista Assets per conservare nome, data, note e repository.
Decisione di aggiornamento
Quando testare nuove release di Citron
Più recente non significa automaticamente migliore. Collega l'update a un problema preciso e confronta con la base.
Usa il tag stabile come controllo
Scegli la versione datata per la prima configurazione, un confronto ripetibile o la verifica di una regressione CI.
- Avvia prima stable.
- Registra renderer, controller e contenuto.
- Tieni stable mentre provi un altro canale.
Usa CI per una modifica precisa
Un build CI ha senso quando le note corrispondono al bug o al fix di piattaforma che cerchi. Non è una garanzia.
- Cambia una sola variabile.
- Conserva commit e piattaforma.
- Torna a stable se il risultato peggiora.
Flusso di aggiornamento sicuro
Testa una nuova release in modo ripetibile
Questa sequenza mantiene chiaro il confronto e fornisce prove sufficienti per annullare una modifica.
Descrivi prima il problema
Annota cosa fallisce, su quale piattaforma, con quale contenuto e se stable mostra già il problema.
Leggi le note corrette
Apri il tag ufficiale o la release CI e cerca fix, regressioni, cache o migrazioni.
Registra l'identità
Salva repository, tag o commit, data, nome del file e architettura prima di scaricare.
Fai il backup della configurazione
Conserva configurazione, salvataggi e build funzionante. Il nuovo archivio non è un backup.
Prova una variabile
Usa lo stesso dispositivo, impostazioni e caso di test. Non cambiare build e renderer insieme.
Mantieni o torna indietro
Confronta con la base e conserva il nuovo solo senza una regressione bloccante.
Piano di rollback
Conserva una versione nota prima dell'update
Il ritorno più semplice usa cartelle separate. Tieni stable 2026-04-27 in una cartella, prova CI in un'altra e non mescolare cache o configurazione finché il test non è concluso.
Se il nuovo build non parte, mostra una schermata nera, cambia input o rallenta, avvia prima la cartella stable. Non cambiare contemporaneamente driver, firmware e grafica.
Se hai sostituito il build, ripristina il backup e ripeti lo stesso test. Registra il commit che ha causato la regressione e quello che ha recuperato il risultato.
- Tieni stable e CI in cartelle separate.
- Fai backup di configurazione e salvataggi prima di sostituire.
- Ripristina la base prima di cambiare impostazioni.
- Conserva insieme URL, commit, nome asset e note.
Problemi legati alle release
Usa l'identità della versione per restringere la causa prima di cambiare impostazioni non correlate.
| Sintomo | Controllo iniziale | Passo successivo |
|---|---|---|
| La pagina dice latest ma il tag non è chiaro | Leggi repository, tag o commit e data. | Salva l'identità ed evita mirror. |
| Il nuovo build non parte | Conferma sistema, architettura, formato e cartella pulita. | Torna al build noto prima di regolare. |
| Il gioco si comporta diversamente | Cerca cambiamenti di renderer, cache o compatibilità. | Ripeti il test in stable con entrambe le identità. |
| Lo ZIP sorgente sembra un installer | Leggi etichetta dell'asset e contesto. | Scegli il pacchetto pronto per la piattaforma. |
FAQ
FAQ sulle release di Citron
Dove sono le release ufficiali di Citron?
Usa Releases di citron-neo/emulator per i tag datati e Releases di citron-neo/CI per i build mobili per piattaforma. Controlla il proprietario nell'URL.
Qual è la versione stable verificata?
Il tag stabile verificato il 23 ottobre 2026 è 2026-04-27. Riapri la pagina ufficiale prima di installare.
Un commit CI è una versione stable?
No. Un commit CI identifica un build automatizzato che può essere più recente e contenere modifiche o regressioni specifiche della piattaforma.
Come leggo le note di una release Citron?
Parti dall'identità e cerca compatibilità, renderer, cache, migrazione della configurazione, problemi noti e note sugli asset.
Una release fornisce giochi, firmware o chiavi?
No. Fornisce file e note del progetto. Usa solo file che hai il diritto di ottenere dalle tue fonti.
Cosa fare se una nuova release rompe il setup?
Torna a stable, tieni il nuovo build separato e annota commit, asset, scenario e regressione prima di segnalarla.
Fonti ufficiali
Fatti e link delle release
Gli esempi delle release di Citron provengono da pagine ufficiali verificate il 23/10/2026. Riaprile per un asset aggiornato.
- Releases di citron-neo/emulatorTag datati, descrizioni e asset stabili.
- Releases di citron-neo/CIBuild Windows, Linux, macOS e Android.
- Citron NEO all buildsIndice che riporta i controlli a GitHub.