Closed Pierlou closed 5 months ago
Merci pour ce retour Thibaut ! :pray: Point par point :
version
Update : j'ai modifié le code pour prendre en compte les datapackages et j'ai initié une PR sur le repo template : https://github.com/etalab/datapackage-template/pull/1 (qui montre d'ailleurs une incohérence due à l'absence d'un v
comme tu le faisais remarquer Pierre). Tu pourras tester de ton côté Thibaut ?
Tu pourras tester de ton côté Thibaut ?
@Pierlou merci ! J'ai bien noté, je testerai et je te ferai un retour global aussi.
... Nous pouvons aussi changer le pattern pour que le
v
soit facultatif, qu'en penses-tu ? ...
Comme nous sommes à l'origine du pattern et que nous avons l'opportunité de participer au groupe de travail pour la v2 de la spec, je dirais qu'on a tout intérêt à essayer de pousser un format unique avec le "v" ! (et donc garder le comportement actuel de ton script)
je dirais qu'on a tout intérêt à essayer de pousser un format unique avec le "v"
En réalité ici il s'agit uniquement de la détection des versions dans le schéma, pas de l'intention du choix du format. Dans la dernière version du script, le pattern cherche avec et sans le "v", pour détecter les cas où un schéma aurait des dissonances du type v1.0.0
VS 1.0.0
. En parallèle, je suis effectivement d'accord pour qu'on pousse pour un formalisme unique 🤝
En réalité ici il s'agit uniquement de la détection des versions dans le schéma, pas de l'intention du choix du format. Dans la dernière version du script, le pattern cherche avec et sans le "v", pour détecter les cas où un schéma aurait des dissonances du type
v1.0.0
VS1.0.0
. En parallèle, je suis effectivement d'accord pour qu'on pousse pour un formalisme unique 🤝
Entendu, c'est parfait !
Poke @thbar est-ce que tu as pu te pencher sur le sujet ? 🙏 J'aimerais le passer sur d'autres schémas (on a beaucoup de cas où ce serait bénéfique) La version pour datapackage est ici : https://github.com/datagouv/datapackage-template/pull/1
@Pierlou je viens de faire un test, voilà l'output !
Versions are mismatched within the schema 'schema-irve-statique', expected version '2.3.0' but:
- path has version 'v2.3.0'
- resources[0].path has version 'v2.3.0'
Versions are mismatched within the schema 'schema-irve-dynamique', expected version '2.3.0' but:
- path has version 'v2.3.0'
- resources[0].path has version 'v2.3.0'
Voir:
C'est déjà chouette, je vais amender dans ce sens !
Il serait utile, à terme, d'avoir un check "pre-release" qui vérifie quand on pose un tag/crée une release que le tag ex: 'v2.3.1` est raccord avec ce qui est dans le schéma, et d'empêcher la création du tag/release si cela est possible ! (là ce n'est pas raccord chez nous, par exemple).
Chouette boulot, ça me paraît bien, je vais conserver de notre côté.
Merci pour ce retour ! En effet dans l'idéal ce serait bien d'avoir un process qui gère un peu tout (checks de cohérence, montée de version...). On pourrait imaginer un script qui passe lors d'une nouvelle release, mais je ne suis pas sûr de voir comment ça s'articulerait : l'action ici est sur un push, donc on a encore le temps d'amender avant de merge, mais lors de la création d'une release on n'a pas cette étape intermédiaire, donc on serait sur un test a posteriori ? Preneur d'idées sur le sujet
On a l'air d'avoir atterri sur un bon premier jet, merci à tous pour vos retours ! Je vous propose de continuer nos échanges sur le sujet dans cette issue
Merci pour cette review Pierre ! Pour les numéros de versions, nous cherchons à standardiser l'utilisation de
vX.Y.Z
pour les schémas de schema.data.gouv, dans un souci de cohérence, d'où ce choix. Nous pouvons aussi changer le pattern pour que lev
soit facultatif, qu'en penses-tu ? De même dans les schémas que nous supervisons, les champshomepage
etversion
sont attendus, nous y serons vigilants.