Le 18 août, Mastodon a montré une partie de 5.0 : un nouveau composer, une navigation revue, les « private mentions » renommées en messages, des réglages de visibilité plus explicites et davantage de place donnée au nom de l’instance.1
Deux jours plus tard, un détail reste facile à manquer : Mastodon 5.0 n’est pas une release que l’on peut installer.
La dernière version stable publiée est 4.6.6 ; la branche 4.7 possède déjà une première release candidate, tandis que main s’identifie aujourd’hui comme 4.8.0-alpha.1.345
Ce décalage raconte assez bien la manière dont un gros projet open source prépare une rupture de version. Les choses difficiles n’attendent pas toujours le numéro qui les résume.
Avant cinq
Les notes de 4.7-rc.1 sont beaucoup moins photogéniques que les mockups de 5.0, mais elles contiennent la phrase la plus importante pour un administrateur : cette version doit préparer la migration sans coupure vers le futur Mastodon 5.0.3
4.7 représente déjà une étape conséquente pour l’exploitation.
La release candidate impose de recompiler les assets, de redémarrer le serveur de streaming et de faire évoluer le schéma PostgreSQL. Mastodon prévient aussi que certaines migrations peuvent durer jusqu’à plusieurs heures sur de très grosses instances.3
Elle déplace les paires de clés des comptes locaux vers une table dédiée et chiffre désormais les clés privées au repos. Ed25519 rejoint les HTTP Message Signatures, de nouveaux Object Integrity Proofs sont vérifiés, plusieurs FEP ActivityPub deviennent compris par Mastodon et l’identification des acteurs distants change afin de mieux gérer leurs changements de handle.3
Autrement dit, si l’on cherche les « fondations » de 5.0, une bonne partie se trouve déjà dans une version qui porte encore un 4.
Deux chantiers
Cette séparation devient encore plus nette quand on compare les sources.
Le billet « 5.0: Laying the foundation » parle presque exclusivement de compréhension de l’interface : comment publier, qui verra le post, qui pourra le citer, où retrouver un message, comment une instance affiche son identité et comment les listes deviennent des « custom feeds » plus visibles.1
La Discovery Week publiée deux semaines plus tôt expliquait pourquoi. L’équipe explique crouler sous des milliers de retours GitHub et voulait surtout comprendre les difficultés qui concernent aussi les utilisateurs moins techniques.2
5.0 est donc présenté comme une refonte du modèle mental avant d’être présenté comme une nouvelle pile serveur.
C’est particulièrement visible avec les messages privés. Techniquement, Mastodon ne transforme pas soudain son architecture en messagerie instantanée indépendante : le projet change d’abord le vocabulaire et l’expérience pour que l’utilisateur sache clairement qu’il envoie quelque chose de privé.1
Dans main
IRZ a comparé le tag v4.7.0-rc.1 avec main au commit 60593f6, le 20 août.
Entre les deux : 79 commits, 261 fichiers modifiés, 10 133 lignes ajoutées et 4 336 supprimées.
Sur ces changements, app/javascript représente à lui seul 189 fichiers, +8 064 lignes et −1 451 lignes ; les contrôleurs, helpers, services et bibliothèques Rails hors JavaScript totalisent seulement 11 fichiers dans notre regroupement, avec +25/−50 lignes, et aucun nouveau fichier db/migrate n’apparaît dans ce diff.
Ce constat ne prédit évidemment pas les migrations finales de Mastodon 5.0 : quatre jours de main ne suffisent pas à déduire le contenu d’une version encore en préparation.
Dans cette fenêtre précise, le chantier visible immédiatement après 4.7-rc.1 est donc massivement orienté interface.
Pas encore 5.0
Il faut tout de même poser une barrière importante autour de ce diff.
Les PR de redesign que nous avons vérifiées — nouveau composer, menu de visibilité, navigation, replies et messages — sont bien mergées dans main, mais aucune des huit PR échantillonnées ne porte de milestone 5.0.678
Et main se déclare 4.8.0-alpha.1.5
Le code confirme donc qu’un chantier correspondant aux prototypes publics est déjà bien engagé. En revanche, rien ne permet encore de présenter l’état actuel du dépôt comme « le code final de Mastodon 5.0 ».
Le propre billet de Mastodon insiste d’ailleurs sur le caractère provisoire des mockups et captures.1
Cette nuance compte pour les administrateurs. Un article de design n’est pas un guide d’upgrade. Une PR de navigation n’est pas une migration. Et un numéro majeur annoncé n’est pas encore un calendrier de maintenance.
Le vrai coût
Pour une petite instance, la question utile n’est donc pas « combien coûte 5.0 aujourd’hui ? ». Personne ne dispose encore des notes d’upgrade 5.0 permettant de répondre proprement.
La bonne question est : quels coûts sont déjà certains sur la route qui y mène ?
4.7 apporte une réponse concrète. Les dépendances externes restent celles de 4.6 : Ruby 3.3+, PostgreSQL 14+, Redis 7+, Node 22+, libvips 8.13+, FFmpeg 5.1+ et éventuellement Elasticsearch 7.x ou OpenSearch pour la recherche.3
En revanche, l’administrateur doit prévoir les migrations pre-deployment puis post-deployment, et sauvegarder sa base avant l’opération. La release candidate rappelle également qu’après passage sur cette préversion, revenir proprement vers les versions stables actuelles n’est pas garanti.3
Sur une petite instance, « migrations longues » ne veut évidemment pas dire plusieurs heures. L’avertissement vise les très gros serveurs. Mais le type de travail reste le même : sauvegarde, lecture des notes intermédiaires, validation de la base, redémarrage des processus, contrôle après migration.
La décentralisation produit ici son coût habituel : Mastodon GmbH développe le logiciel, mais chaque administrateur indépendant reste responsable de sa propre trajectoire de versions.
L’identité locale
Le redesign 5.0 insiste aussi sur une autre conséquence de cette décentralisation : l’interface doit moins donner l’impression d’un seul grand service Mastodon.
Dans les mockups, le nom et l’icône de l’instance remontent dans la navigation, tandis que la marque Mastodon devient un discret « Powered by Mastodon ».1
Ce détail visuel est cohérent avec le reste du chantier. Mastodon essaie de rendre explicite une architecture qui a longtemps demandé aux utilisateurs de comprendre des abstractions assez techniques : serveur d’inscription, fédération, portée d’un post, mentions privées, listes, timelines locales et fédérées.
L’équipe ne supprime pas ces concepts. Elle tente de mieux montrer lesquels importent à quel moment.12
Version majeure
Il est alors tentant de demander pourquoi tout cela mérite un « 5.0 » plutôt qu’un « 4.8 ».
Pour l’instant, la question n’a pas de réponse technique définitive publique. Le dépôt dit 4.8 alpha ; le blog parle de 5.0 ; 4.7 prépare explicitement la migration future. Ces trois faits coexistent.135
Mais ils montrent quelque chose d’intéressant sur les numéros de version d’un produit utilisé par des humains.
Une version majeure ne correspond pas forcément au commit qui contient la migration la plus douloureuse. Elle peut aussi servir à désigner le moment où un produit change la manière dont il explique ses propres concepts.
Ici, la base technique évolue en amont, puis l’interface tente de rendre Mastodon moins dépendant de la connaissance historique de Mastodon.
Pour les admins
Si vous gérez une petite instance, la conclusion au 20 août est finalement assez simple.
Ne planifiez pas encore une migration “5.0” comme si les notes existaient : le billet du 18 août présente une direction et des prototypes, pas des instructions d’exploitation.1
En revanche, lisez sérieusement 4.7 : elle contient aujourd’hui les changements de schéma PostgreSQL, de clés et de protocoles explicitement présentés comme nécessaires avant 5.0.3
Et si vous développez un thème, une intégration ou une interface autour de Mastodon, surveillez main : le composer et la navigation bougent déjà à grande vitesse.5678
La drôle de leçon de Mastodon 5.0, pour l’instant, est donc que son travail de fond se déroule en partie avant sa propre existence.
Le numéro arrivera plus tard, alors que migrations, nouvelles signatures et centaines de fichiers d’interface ont déjà commencé à bouger.