You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Cette PR (et son équivalent pour les datapackages) a introduit un test de cohérence lors de la création et la montée de version de schémas de données. L'idée est de faciliter la vie des mainteneurs afin de pointer les potentiels oublis.
D'autres types de scripts pourraient être envisageables dans la même optique :
lorsque des changements sont faits sur un schéma, on pourrait avoir un script qui modifie directement toutes les références à la version pour l'incrémenter (même idée que bumpr)
un script qui gère automatiquement la release du schéma une fois que toutes les modifications sont faites (une Github action on: merge [main] par exemple), qui crée une release et un tag à partir de la nouvelle version indiquée dans le schéma
Preneur d'idées !
The text was updated successfully, but these errors were encountered:
Merci pour la réflexion ! Je suis davantage preneur d'un script qui "bloquerait" la release, qu'on conserverait faite à la main, que d'un script qui génèrerait automatiquement la release. Je préfère en effet conserver la main sur ce qui se passe à ce niveau là, d'autant plus que les montées de versions sont peu nombreuses. Just my 0.02$!
Cette PR (et son équivalent pour les datapackages) a introduit un test de cohérence lors de la création et la montée de version de schémas de données. L'idée est de faciliter la vie des mainteneurs afin de pointer les potentiels oublis.
D'autres types de scripts pourraient être envisageables dans la même optique :
bumpr
)on: merge [main]
par exemple), qui crée une release et un tag à partir de la nouvelle version indiquée dans le schémaPreneur d'idées !
The text was updated successfully, but these errors were encountered: