Verrouillage des versions des plugins et thèmes pour les anciennes installations de Discourse (.discourse-compatibility)

[Discourse]

Contexte

Parfois, les thèmes/plugins doivent apporter des modifications qui ne sont compatibles qu’avec la dernière version de Discourse. Dans ce cas, les anciennes versions de Discourse peuvent être configurées pour utiliser une ancienne version ‘épinglée’ du plugin.

Ceci est réalisé à l’aide d’un fichier .discourse-compatibility à la racine d’un dépôt de thème/plugin. C’est un fichier YAML où les clés spécifient la version principale de Discourse, et les valeurs représentent la version associée de votre thème/plugin.

Les versions principales de Discourse peuvent être spécifiées à l’aide des opérateurs <= et <. <= est la valeur par défaut pour des raisons historiques, mais généralement il est plus logique d’utiliser <.

Épinglage d’une version de thème/plugin

Par exemple, si le cœur de Discourse apporte une modification lors de 3.2.0.beta2-dev (trouvé dans version.rb) et que votre plugin/thème commence à en dépendre, vous ajouteriez une entrée au fichier .discourse-compatibility comme ceci :

< 3.2.0.beta2-dev: abcde

où abcde est une référence au hash de commit ‘legacy’ DE VOTRE PLUGIN qui doit être utilisé sur les anciennes versions de Discourse.

Désormais, toute personne utilisant une ancienne version de Discourse (par exemple, 3.2.0.beta1 ou 3.1.4) utilisera la version abcde de votre thème/plugin. Toute personne sur 3.2.0.beta2-dev ou une version ultérieure continuera à utiliser la dernière version.

Entrées multiples

Au fil du temps, vous pouvez ajouter plusieurs lignes au fichier .discourse-compatibility. Discourse choisira toujours la spécification la ‘plus basse’ qui correspond à la version principale actuelle de Discourse. L’ordre des lignes dans le fichier n’a techniquement pas d’importance, mais nous recommandons de placer les entrées les plus récentes en haut.

‘Backporting’ des modifications pour les anciennes versions de Discourse

Imaginons un fichier .discourse-compatibility comme celui-ci, avec deux spécifications de version différentes épinglées à des commits de plugin spécifiques :

< 3.2.0.beta1-dev: commithashfordiscourse31
< 3.1.0.beta1-dev: commithashfordiscourse30

Si vous avez besoin de ‘backporter’ une modification vers Discourse 3.1, vous feriez quelque chose comme ceci :

1. Créez une branche à partir de l’ancien commit (git checkout -b my_branch_name commithashfordiscourse31)

2. Validez votre modification et poussez-la vers l’origine. Si vous utilisez les fonctionnalités de protection de branche de GitHub, vous voudrez peut-être protéger cette branche contre la suppression accidentelle.

3. Mettez à jour le fichier .discourse-compatibility sur la branche principale afin qu’il pointe maintenant vers votre nouveau commit sur la branche de support 3.1.

Exemple concret

Voici un fichier .discourse-compatibility réel du plugin discourse-solved. Notez qu’au moment de la rédaction, il utilise toujours la syntaxe ‘legacy’ sans opérateurs < ou <= explicites. Par conséquent, chaque ligne est automatiquement interprétée comme <=.

.discourse-compatibility

---

Ce document est contrôlé par version - suggérez des modifications sur github.

[NateDhaliwal]

Si la version est < 3.5.0.beta8-dev, inclurait-elle 3.5.0 ?

[david (David Taylor)]

Non. 3.5.0 est considéré comme « supérieur » à la version prerelease « 3.5.0.beta8-dev ».

Vous pouvez toujours essayer des comparaisons sur une console ruby :

> Gem::Version.new("3.5.0") < Gem::Version.new("3.5.0.beta8-dev")
=> false

[NateDhaliwal]

Compris. Merci pour l’explication !