Files
Loki/RELEASE_NOTES.md
T
nathaninline 75929e7b60 Migration automatique de l'agencement systeme (Unix)
Sans ca, le renommage n'atteignait pas les machines Linux installees. Le
dossier de donnees y est epingle par /etc/default/jean, que notre propre
installeur ecrit ; le code traitant un chemin explicite comme un ordre, il
ne migrait jamais. Constate en deployant 0.7.0 sur un vrai serveur : les
chemins sont restes en /etc/jean et il a fallu un script separe.

La regle qui debloque : distinguer NOTRE artefact du CHOIX de l'utilisateur.
Si le chemin epingle vaut exactement l'ancien emplacement par defaut, c'est
notre installeur qui l'a ecrit et on migre. Toute autre valeur est une
decision de l'utilisateur et reste intacte.

Le dossier, /etc/default et l'unite systemd bougent ENSEMBLE : les separer
donnerait le pire cas, des donnees deplacees et un service qui ne redemarre
plus. Les chemins sont reecrits par parcours du dossier plutot que d'apres
une liste devinee — l'experience montre qu'ils se cachent dans EXTRA_ARGS,
les copies .bak et jusque dans des notes de MEMORY. backends/ et les .gguf
sont sautes.

Deux moments de declenchement, tous deux root et deliberes : `install`, et
juste apres une mise a jour reussie. Jamais au demarrage ordinaire — un
service qui reecrit des unites systemd a chaque boot finirait par en casser
une, et sur un parc entier ca veut dire des machines qui ne redemarrent plus.

La variante post-mise-a-jour n'arrete AUCUN service : on s'execute dans
jean-link, l'arreter reviendrait a se tuer au milieu de la migration, dossier
deplace et chemins pas encore reecrits. Sans danger, un rename de dossier
sous Linux tolere les fichiers ouverts et un process garde son repertoire de
travail par son inode.

Sauvegarde prealable bloquante, et retour a l'etat initial si une etape
echoue apres le deplacement. Couvert par 6 tests sur un faux /etc, dont le
respect d'un chemin impose et la garantie qu'aucun service n'est touche par
la variante post-MAJ.
2026-08-04 16:23:20 +02:00

3.0 KiB

Jean devient AJEAN, partout et plus seulement dans l'interface. Le dépôt, la commande, les fichiers, les dossiers et les services portent désormais le même nom.

Cette version a été construite autour d'une contrainte simple : rien de ce qui fonctionne aujourd'hui ne doit cesser de fonctionner. Il n'y a rien à réinstaller et rien à reconfigurer.

La commande jean continue de marcher

ajean devient la commande principale, mais jean reste installée à côté et fait exactement la même chose. Les alias, les scripts, les tâches planifiées et les raccourcis existants ne bougent pas.

De même, JEAN_HOME reste lu s'il a été défini à la main, au même titre que le nouveau AJEAN_HOME. Un emplacement choisi explicitement est un choix, pas un héritage à corriger.

Le dossier de données se renomme tout seul

%ProgramData%\jean devient %ProgramData%\ajean, et /etc/jean devient /etc/ajean sous Linux et macOS. Vous n'avez aucune commande à lancer : la migration se fait pendant la mise à jour.

Le déplacement est instantané, même avec 200 Go de modèles — rien n'est recopié, le dossier est renommé sur place. Tout ce qui pointait dedans suit : les chemins absolus de config.env, ceux de vos presets (dont le --chat-template-file), le fichier /etc/default, et le répertoire de travail de l'unité systemd.

Votre clé d'accès distant est déplacée avec le reste : aucun ré-appairage, le tunnel se reconnecte seul.

Si vous aviez choisi vous-même l'emplacement — un JEAN_HOME sur un autre disque, par exemple — il n'est pas touché. Un chemin défini à la main est une décision, pas un héritage à corriger.

Et si le renommage ne peut pas aboutir, par exemple parce qu'AJEAN tourne encore en tâche de fond sous Windows, il ne se passe rien du tout : l'ancien dossier reste en place et continue de servir, la tentative sera reprise plus tard. Rien n'est jamais copié ni supprimé.

Les serveurs Linux ne perdent pas la main

Les unités systemd ne sont pas renommées. Un serveur qui tourne sous jean.service continue sous jean.service : vos commandes systemctl, vos règles sudoers et vos scripts de supervision restent valables. Seuls les chemins qu'elles contiennent sont corrigés, et une copie de l'unité d'origine est conservée à côté.

Une sauvegarde de la configuration, des presets et de la mémoire est déposée dans /root avant toute modification. En cas d'échec à n'importe quelle étape, la machine est remise dans son état initial et les services relancés.

Mise à jour

ajean update

Les binaires restent publiés sous leurs deux noms, ajean-* et jean-*, le temps que le parc bascule. Les installations existantes se mettent donc à jour normalement, sans intervention.

Sous Windows, télécharger ajean-windows-amd64.exe depuis cette page et le lancer fait le même travail : le fichier détecte l'installation existante et propose de la remplacer.

L'icône de la barre de menus macOS, introduite en 0.6.10, n'a toujours pas été vérifiée sur une vraie machine.