Documentation sur la surcharge de fichiers

Il a été acté que les surcharges de fichier n’étaitent pas concernées par semver
Voir ici Semver et surcharges de fichiers du noyau et la décision en elle-même

Ce serait à documenter d’une manière ou d’une autre sur spip.net, en fonction de l’organisation de la doc que vous envisagez.

Merci à vous ! :slight_smile:

Ce que je verrais bien

  1. Un petit article introductif au semver et au processus de release (cf ce fil [Résolu] Rythme de parution des nouvelles versions SPIP qui montre une confusion chez certain·es sur les différents types de maj)
  2. Qui précise donc du coup le point sur semver
  3. Renforrcer l’avertissement ici Surcharger un fichier - Programmer avec SPIP 4
  4. Corriger les remarques ici Où placer les fichiers de squelettes ? - SPIP qui sont vraiment pas top vu que poussent à surcharger…

1 & 2 gogogo
3 je trouve que c’est déjà suffisamment clair
4 +1 pour virer le dernier bloc de remarques

sur 3 je pensais juste rajouter que « notamment hors semver »
sur 4 je pense qu’on peut garder le § paragraphe de la remarque, mais remplacer celui de la seconde.

J’ai tenté rapidement de pondre ca

https://semestriel.framapad.org/p/comprendre_les_versions_de_spip-ab59?lang=fr

je suis pas hyper satisfait…

Après discussion avec jack31

  • 1 + 2 le pad a été mis ici SPIP l’article sera publié lundi prochain, sauf contre ordre, comme cela ca traine pas
    1. Avertissement complété
    1. Remarque de fin corrigé pour bien dire que c’est pas bien.

@rastapopoulos propose de fusionner le nouvel article dans SPIP pour avoir un seul truc sur « tout ce qui est numerotation de version ». cela me parait plutot logique. qu’en pensez vous ?

Initialement, j’aurais pensé qu’une simple référence à la traduction fr de semver suffirait : https://semver.org/lang/fr/#gestion-sémantique-de-version-200 . Je ne comprends pas trop l’intérêt d’avoir sa propre interprétation …

L’article cible ayant pour vocation à exposer un contenu informatif et technique le plus automatisé possible, mettre une couche de texte (à traduire), n’a pas trop de sens, à mon avis. C’est mettre de « l’éditorial » là où ce n’est pas nécessaire …

la traduction est assez technique, l’idée c’était d’avoir un truc plus « guidé » pour le commun des mortel·les

Si vous souhaitez faire référence au code couleur, ou reprendre un des tableaux de la page « Versions Maintenues », ce sont des modèles SPIP, ils peuvent être ajoutés dans d’autres articles.

Parce que ça l’est. C’est une codification technique, et elle n’est quand même pas si compliqué …

Si vous y tenez, mais dans ce cas, autant éviter de faire un mélange des genres. Page informative et simple d’un coté. Contenu éditorialisé à vocation « pédagogique » de l’autre.

Mon propos était inverse, du point de vue lecteurices de la doc, il me semble que ce n’est pas top d’avoir mille petits articles parlant de choses très proches : aussi bien par les moteurs de recherche que par des liens dans les forums, les gens vont tomber sur un article et pas un autre, et ne vont jamais avoir toute l’information d’un même sujet au même endroit (je parle bien quand on traite d’un sujet quasi similaire).

Il y a déjà un peu trop d’articles différents qui pourraient être redécoupés/fusionnés concernant « comment télécharger/installer SPIP », et donc là concernant « l’explication des versions, et quand faire les mises à jour de quoi (sécu, bugs, etc) » il me semble que c’est un même unique sujet, à traiter au même endroit pour tout le monde.

Alors certes en arrière-plan c’est pas construit pareil (une partie automatisée), mais pour les gens c’est un même sujet, et avoir une unique URL abordant tout me paraissait mieux.

J’avais bien compris.

Et je ne suis pas convaincu. ni que ce soit « un même unique sujet » et que « au même endroit pour tout le monde » soit une bonne idée. Et je ne pense pas que « les gens » et « tout le monde », ce soit une bonne mesure pour prendre des décisions.

Votre texte explicatif ne va pas (ou alors très peu) bouger dans le temps. Il a vocation à expliquer la théorie, voire la stratégie que la communauté applique. Un·e lecteurice n’y retourne pas toutes les semaines une fois qu’iel a compris.

Les pages automatiques le sont, justement parce que les informations qu’elles contiennent évoluent régulièrement, et n’ont vocation à être vues que pour ça, parce que le contenu change. Lae lecteurice y retourne pour ça et ne devrait pas être pollué par un contenu « statique », connu, lu et relu. C’est lourd.

J’irai même jusqu’à penser que le tableau de compat’ PHP est en trop dans la page que vous ciblez, puisque l’info est présente dans le tableau principal. (et qu’on s’attend à trouver la légende d’un tableau plutôt sous le tableau plutôt qu’au dessus, mais bon :slight_smile: …)

Une explication synthétique pourrait parfaitement se trouver sous le tableau, ne polluant pas l’information principale dynamique, mais venant l’expliquer pour celleux qui ne savent pas encore le semver :slightly_smiling_face:

1 « J'aime »

Carrément oui !

Je relis tout cela a froid et la nuit portant conseil.

  1. Je pense que ce sont deux articles différents
  2. Pour autant oui on peut avoir une micro info synthétique (2 lignes max sous le tableau)
  3. Par ailleurs on pourrait mettre le « nouvel » article a coté du second et pas dans la rubrique « evolution et mise à jour »
1 « J'aime »

Ou inversement c’est l’article « Versions maintenues » qui devrait peut-être se trouver dans « Évolutions et mises à jour » puisque ça liste littéralement… les évolutions en cours et à venir.

1 « J'aime »

pas faux :slight_smile:

Du coup ca donne ca

2 « J'aime »