04/07/2023 : Ce wiki entre dans un processus de compostage. À l'origine de cette décision : le constat que le wiki n'est plus du tout utilisé depuis des mois + le manque de temps pour le maintenir et l'améliorer.

Ce processus se fera en 3 étapes :

  • juillet-août-septembre : cette bannière est mise en place pour prévenir les utilisateurices et leur laisser le temps de s'organiser
  • octobre-novembre-décembre : il ne sera plus possible de se connecter au wiki
  • à partir de 2024 : une archive statique du site restera en ligne à la même adresse, sur le même principe que forum.lescommuns.org.

Vous pouvez désormais utiliser yeswiki.lescommuns.org, soit sur le site principal pour des pages ponctuelles (exemple) soit en ouvrant un wiki dédié à votre projet. N"hésitez pas à venir sur le canal de chat communs_wiki pour échanger à propos de ce processus.

Gestion de version

De Wiki des communs

Des règles utiles pour les versions, par Tom Preston-Werner

Dans le monde de la gestion des logiciels, il existe un endroit redouté appelé “l’enfer des dépendances” (de l’anglais “dependency hell”). Plus votre système se développe et plus vous intégrez de composants dans votre logiciel, plus vous êtes susceptible de vous trouver un jour dans cette abîme de désespoir.

Dans les systèmes comportant de nombreuses dépendances, publier une nouvelle version d’un composant peut vite devenir un cauchemar. Si les règles de dépendance sont trop strictes, vous risquez de verrouiller vos versions (incapacité de mettre à jour un composant sans avoir à publier une nouvelle version de chaque composant qui en dépend). Si les règles de dépendances sont trop lâches, vous allez inévitablement subir la promiscuité de version (supposer une compatibilité avec plus de futures versions que raisonnable). L’enfer des dépendances est l’endroit où vous vous trouvez lorsque vous êtes bloqué dans une version et/ou qu’une incompatibilité de version vous empêche d’avancer sans risque dans votre projet.

Comme solution à ce problème, je propose un ensemble de règles et d’exigences simples qui dictent la façon dont les numéros de version sont attribués et incrémentés. Ces règles sont basées mais pas nécessairement limitées à des pratiques très répandues aussi bien dans les domaines du logiciel privé que du logiciel libre. Pour que ce système fonctionne, vous devez d’abord déclarer une API publique. Il peut s’agir d’un document ou de règles imposées par le code lui- même. Quoiqu’il en soit, il est important que cette API soit claire et précise. Une fois prête, vous communiquez ses modifications par des incrémentations successives de son numéro de version. Considérons le format de version X.Y.Z où X, Y et Z identifient la version (Majeure.Mineure.Corrective). Les corrections qui n’affectent pas l’API incrémentent le dernier identifiant qui est l’identifiant de version de correction. Lors d’ajouts ou de modifications rétrocompatibles de l’API, il faut incrémenter l’identifiant de version mineure. Enfin, pour des modifications non rétrocompatibles, il faut incrémenter l’identifiant de version majeure.

J’appelle ce système “gestion sémantique de version”. Avec ce système, les numéros de version, et la façon dont ils changent, donnent du sens au code sous-jacent et à ce qui a été modifié d’une version à l’autre.

http://semver.org/lang/fr/