Guide des notes des versions Citron
Versions Citron : notes de version et guide des builds
Utilisez les pages GitHub de première partie pour identifier un tag stable, lire les changements, choisir le fichier de votre plateforme et garder un point de retour.
Que faut-il vérifier dans les versions Citron ?
Les versions Citron sont réparties entre un tag daté dans le dépôt citron-neo/emulator et des builds de plateforme qui évoluent dans citron-neo/CI. La page stable affiche actuellement le tag 2026-04-27. Une page CI peut publier un commit plus récent sans modifier ce tag : notez donc le dépôt, le tag ou commit, la plateforme et la date de publication.
La description officielle des versions indique ce qui a changé et ce qui a pu être déplacé. Lisez-la avant de remplacer un build fonctionnel : correction du renderer, invalidation du cache, changement de configuration ou régression de plateforme peuvent modifier la bonne décision. Le titre seul ne constitue pas une preuve.
Le 23 octobre 2026, les pages officielles montraient une version CI Linux basée sur le commit 598b700 et datée du 16 octobre. C'est un exemple daté, pas une promesse pour toutes les plateformes. Les canaux CI avancent séparément : rouvrez la page de votre plateforme avant l'installation.
Carte des versions actuelles
Versions Citron vérifiées le 23 octobre 2026
Ces identités expliquent ce que représente chaque page. Les dates sont des relevés et doivent être revérifiées avant une installation.
Tag stable : 2026-04-27
Le tag daté est la meilleure base pour un test reproductible. Il change moins souvent qu'un canal CI et offre un point de restauration clair.
Source : github.com/citron-neo/emulator/releasesLes builds sont identifiés par un commit
Le dépôt CI publie des builds Windows, Linux, macOS et Android. Un commit court est plus utile qu'un libellé générique latest.
Source : github.com/citron-neo/CI/releasesExemple CI Linux : 598b700
La page Linux consultée indiquait le commit 598b700 et la date 2026-10-16. Vérifiez toujours le tag actuel.
Page CI officielle vérifiée le 23/10/2026Les notes ne sont pas des fichiers de jeu
Une version GitHub contient des fichiers et notes du projet, pas de jeux protégés, de fichiers privés de console ou de clés.
Séparez les fichiers de l'émulateur de vos propres fichiers légaux
Lire l'identité avant le journal des changements de versions
Un relevé court évite de considérer chaque tag mobile comme la même version. Enregistrez d'abord l'identité, puis lisez les notes.
| Canal | Identité à noter | Ce que montrent les notes | Action |
|---|---|---|---|
| Stable | Tag 2026-04-27 | Notes et fichiers datés | Servir de référence |
| CI Linux | 598b700, 16/10/2026 | Commit amont et formats | Tester si le correctif est nécessaire |
| CI Windows, Android, macOS | Tag et commit de la plateforme | État propre à la plateforme | Vérifier chaque page |
| Archive source | ZIP généré par GitHub | Instantané pour développeurs | Ne pas l'utiliser comme installateur |
La page officielle des versions est la cible de téléchargement. Évitez les CDN devinés, les liens courts, les installateurs repackagés et les miroirs sans contexte.
Lire les notes
Quatre signaux à rechercher dans les notes des versions Citron
Les notes sont utiles lorsqu'elles répondent à une décision concrète. Cherchez ces signaux avant de télécharger une mise à jour.
Portée de compatibilité ou de régression
Repérez les mentions d'un jeu, renderer, contrôleur, système ou firmware. Un correctif local ne concerne pas forcément toutes les plateformes.
- Notez le sous-système ou la plateforme.
- Distinguez corrigé, modifié, expérimental et problème connu.
- Gardez le build actuel si la note ne concerne pas votre problème.
Changements de configuration et de cache
Les versions peuvent invalider un shader cache, déplacer un dossier utilisateur, modifier les valeurs par défaut ou demander un premier lancement propre.
- Sauvegardez votre configuration.
- Ne recopiez pas un ancien cache sans raison.
- Suivez la procédure de migration de la note.
Indices de fichier et d'architecture
Les noms peuvent distinguer x64, x86_64_v3, aarch64, Android ou macOS. Choisissez le fichier adapté à la machine.
- Confirmez système et architecture.
- Traitez AppImage, ZIP, DMG et APK comme des formats distincts.
- Lisez la description si le suffixe est inhabituel.
Indices pour revenir en arrière
Commit, date et notes rendent un rapport de régression précis. Conservez ces éléments avant le test.
- Gardez le build précédent.
- Notez le scénario et les réglages.
- Communiquez l'identité plutôt que seulement latest.
Choisir un fichier de plateforme sans deviner
Les notes expliquent le changement et la liste des assets indique ce qui peut fonctionner sur votre appareil. Utilisez les deux.
Vérifier le propriétaire
L'adresse doit être sous github.com/citron-neo/ et correspondre au dépôt attendu.
Copier le tag ou commit
Enregistrez le tag stable ou le commit complet affiché dans la description avant le téléchargement.
Associer le système
ZIP Windows, AppImage/tar.zst Linux, DMG macOS et APK Android sont des formats différents.
Associer l'architecture
Choisissez x86_64, x86_64_v3, aarch64 ou Apple silicon seulement si la machine correspond.
Garder le contexte
Téléchargez depuis la liste Assets afin de conserver nom, date, notes et dépôt.
Décider d'une mise à jour
Quand tester de nouvelles versions Citron
Les versions plus récentes ne sont pas toujours les meilleures. Reliez la mise à jour à un problème précis et comparez avec la référence.
Utiliser le tag stable comme contrôle
Choisissez la version datée pour une première configuration, une comparaison reproductible ou la vérification d'une régression CI.
- Lancez d'abord la version stable.
- Notez renderer, contrôleur et état du contenu.
- Gardez-la installée pendant le test d'un autre canal.
Utiliser CI pour un changement précis
Un build CI est pertinent lorsque les notes correspondent au bug ou au correctif de plateforme recherché. Ce n'est pas une garantie.
- Changez une seule variable.
- Conservez commit et plateforme.
- Revenez à stable si le résultat est pire.
Processus de mise à jour sûr
Tester de nouvelles versions de manière reproductible
Cette séquence conserve une comparaison claire et fournit les éléments nécessaires pour annuler un changement.
Décrire le problème
Notez ce qui échoue, sur quelle plateforme, avec quel contenu et si la version stable présente déjà le problème.
Lire les notes correspondantes
Ouvrez le tag officiel ou le build CI et recherchez correctif, régression, cache ou migration.
Enregistrer l'identité
Conservez dépôt, tag ou commit, date, nom du fichier et architecture avant le téléchargement.
Sauvegarder votre configuration
Préservez configuration, sauvegardes et build fonctionnel. L'archive nouvelle n'est pas une sauvegarde.
Tester une variable
Utilisez le même appareil, les mêmes réglages et le même cas de test. Ne changez pas renderer et build ensemble.
Conserver ou annuler
Comparez à la référence et gardez le nouveau build uniquement s'il résout le problème sans régression bloquante.
Plan de retour
Garder des versions connues avant la mise à jour
Le retour le plus simple se fait avec des dossiers séparés. Gardez le stable 2026-04-27 dans son dossier, testez CI dans un autre et ne mélangez pas caches ou configurations avant la fin.
Si le nouveau build ne démarre pas, affiche un écran noir, modifie les contrôles ou ralentit, relancez d'abord le dossier stable. Ne changez pas en même temps pilotes, firmware et paramètres graphiques.
Si vous avez remplacé le build, restaurez votre sauvegarde puis répétez le même test. Notez le commit qui a causé la régression et celui qui rétablit le résultat.
- Gardez stable et CI dans des dossiers séparés.
- Sauvegardez configuration et sauvegardes avant de remplacer un build.
- Restaurez la référence avant de modifier les réglages.
- Conservez URL, commit, nom d'asset et notes ensemble.
Problèmes liés aux versions
Utilisez l'identité des versions pour réduire le champ avant de modifier des paramètres sans rapport.
| Symptôme | Vérifier d'abord | Étape suivante |
|---|---|---|
| La page dit latest sans tag clair | Lire dépôt, tag ou commit et date. | Enregistrer l'identité et éviter un miroir. |
| Le nouveau build ne démarre pas | Confirmer système, architecture, format et dossier propre. | Revenir au build connu avant les réglages. |
| Le comportement change | Chercher changements de renderer, cache ou compatibilité. | Refaire le test en stable avec les deux identités. |
| Le ZIP source ressemble à un installateur | Lire le libellé de l'asset et le contexte. | Choisir l'asset prêt pour la plateforme. |
FAQ
FAQ des versions Citron
Où trouver les versions officielles de Citron ?
Utilisez Releases de citron-neo/emulator pour les tags datés et Releases de citron-neo/CI pour les builds par plateforme. Vérifiez le propriétaire de l'URL.
Quelle est la version stable vérifiée ?
Le tag stable vérifié le 23 octobre 2026 est 2026-04-27. Rouvrez la page officielle avant l'installation.
Un commit CI est-il une version stable ?
Non. Un commit CI identifie un build automatisé qui peut être plus récent et comporter des changements propres à une plateforme.
Comment lire les notes d'une version Citron ?
Commencez par l'identité puis cherchez compatibilité, renderer, cache, migration de configuration, problèmes connus et remarques sur les assets.
Une Release fournit-elle jeux, firmware ou clés ?
Non. Elle fournit les assets et notes du projet. Utilisez seulement les fichiers que vous avez le droit d'obtenir par vos propres moyens.
Que faire si une nouvelle version casse l'installation ?
Revenez à stable, gardez le nouveau build à part et notez commit, asset, scénario et régression avant de la signaler.
Sources officielles
Faits et liens de versions
Les exemples de versions Citron viennent de pages officielles vérifiées le 23/10/2026. Revérifiez-les pour un asset actuel.
- Releases de citron-neo/emulatorTags datés, descriptions et assets stables.
- Releases de citron-neo/CIBuilds Windows, Linux, macOS et Android.
- Citron NEO all buildsIndex qui renvoie les contrôles vers GitHub.