Versionage sémantique sur le modèle

[laem]

Notre premier réintégrateur nous exprime ce besoin.

Versionage sémantique

À chaque changement du modèle, si le changement est cassant, publier une nouvelle version majeure (2.1.2 -> 3.0.0) pour signaler le changement cassant. Par exemple, une variable d'entrée renommée.

MAJOR version when you make incompatible API changes

À l'inverse si c'est par exemple juste la documentation d'une variable qui est améliorée, c'est un changement mineur (2.1.2 -> 2.1.3).

Si c'est une amélioration de calcul, ou de fonctionnalité, par exemple une nouvelle aide, c'est une version mineure.

MINOR version when you add functionality in a backward compatible manner

Si c'est une correction de bug sans incidence sur les réintégrateurs, c'est une version dite patch.

PATCH version when you make backward compatible bug fixes

Externalisation du modèle ?

Dans un premier temps, je pense que nous devons garder le modèle et le code JS sur le même dépot, et les versions sont unifiées : on y met les changement de l'interface comme du modèle.

Dans un second temps, nous pourrons imaginer découpler les deux.

Prise en compte dans l'API

Dans un second temps, on pourra publier paquet NPM à chaque changement de version qui expose le modèle publicodes. On peut aussi inscrire dans l'URL de l'API exposée par /api/routes.ts le numéro de version.

Et prendre les demandes de nos réintégrateurs au fur et à mesure.

[laem]

En le faisant je me dis qu'un gros fichier "CHANGELOG.md" dans le dossier app/rules serait plus pertinent, avec l'avantage de sérare les notes de version UI dans /releases des notes de version modèle dans le code (moins grand public).

On peut le faire pour les prochains changements.