GeotrekCE / Geotrek-rando-widget

Web components to display Geotrek content on any website
https://geotrek-rando-widget.readthedocs.io
MIT License
5 stars 1 forks source link

[Documentation] Use the number of version in scripts instead of latest #115

Closed bruhnild closed 2 months ago

camillemonchicourt commented 2 months ago

Je suis pas vraiment d'accord avec cette approche. Par défaut, je pense au contraire qu'il vaut mieux taper sur la version la plus à jour. Car sinon les utilisateurs ne bénéficieront pas des améliorations et corrections du widget. Déjà car ils ne sauront pas informés quand de nouvelles versions seront disponibles. Et aussi car ils passent souvent par un prestataire pour leur mettre en place le widget, et donc ils vont devoir demander à celui-ci, potentiellement payer, pour chaque mise à jour.

Le fait d'épingler une version est intéressant à préciser pour ceux qui voudraient fixer une version et être certain qu'elle change pas, mais je la conseillerai pas comme solution privilégiée en production.

babastienne commented 2 months ago

@camillemonchicourt prendre la dernière version par défaut c'est s'exposer à des comportements différents dans le temps.

En test ce n'est pas un problème mais certains territoires qui mettent du temps à travailler sur le style ne comprendraient pas si du jour au lendemain leur site se met à afficher autre chose, des données différentes. C'est pour ça que la documentation recommande de mettre une version stable en production, pour qu'il n'y ai pas d'imprévus et des comportements non désirés qui arrivent en production.

De manière générale tout outil ne doit jamais imposer d'utiliser sa dernière version, l'utilisateur doit être acteur pour faire une montée de version et ne doit pas la subir, c'est ça la bonne pratique à respecter. Si on met dans la doc "utilisez latest", on s'expose au moment d'une nouvelle release à des retours négatifs d'utilisateurs qui ne comprennent pas les changements qui viennent d'arriver sur leur site. Si au contraire on préconise de figer un version en production cela permet de conserver un comportement stable. après si certains veulent continuer d'utiliser latest en production libre à eux, mais ils ne pourront pas se retourner contre nous si lors d'une release des éléments évoluent : on préconise le choix de la sécurité, donc pour moi ça a tout à fait sa place dans la doc.

bruhnild commented 2 months ago

Je pense que c'est intéressant de noter les deux possibilités pour que l'utilisateur puisse choisir la solution la plus adaptée en tout connaissance de cause

image

camillemonchicourt commented 2 months ago

Oui c'est bien d'indiquer les 2 et les avantages et inconvénients qu'ils ont.

Tous les gros widgets que je connais ne sont pas versionnés et sont améliorés et corrigées régulièrement sans devoir chaque fois aller modifier le code source.

Bien sûr que pour un outil on utilise une version bien spécifique et on met à jour quand on veut en connaissance de cause. Un widget c'est différent de tout ce que j'ai pu voir. Selon moi, à nous de ne pas faire de breaking change ou alors de faire des versions majeures du widget quand il y a des breaking changes.

Dans l'usage, les utilisateurs demandent à leur prestataire web d'intégrer le widget et n'y reviennent pas.