Open hjonin opened 1 year ago
status dont la valeur (Concept, Alpha, Beta, RC, Stable) est calculée à partir du numéro de version (cf. SemVer)
Est-ce qu'il y a une correspondance standard calculable pour déduire [Concept|Alpha|Beta|RC|Stable] depuis le numéro de version ?
D'instinct je suis un peu sceptique sur une automatisation ici, mais de la doc m'intéresse.
Décrire les points d'API et les modèles de données actuels
Les schémas de données sont ici :
https://git.sr.ht/~codegouvfr/codegouvfr-fetch-data/tree/master/schemas/
Mais ces descriptions peuvent être mises plus en avant.
Merci pour tous ces éléments !
status dont la valeur (Concept, Alpha, Beta, RC, Stable) est calculée à partir du numéro de version (cf. SemVer) Est-ce qu'il y a une correspondance standard calculable pour déduire [Concept|Alpha|Beta|RC|Stable] depuis le numéro de version ? D'instinct je suis un peu sceptique sur une automatisation ici, mais de la doc m'intéresse.
Normalement oui, on devrait pouvoir extraire avec une regexp le type de version de pré-release (Alpha, Beta, RC) après le tiret (https://semver.org/#spec-item-9). Concept serait un code source sans version et Stable une version stable.
Moyennant bien sûr que le code source suive cette sémantique :)
Décrire les points d'API et les modèles de données actuels Les schémas de données sont ici : https://git.sr.ht/~codegouvfr/codegouvfr-fetch-data/tree/master/schemas/ Mais ces descriptions peuvent être mises plus en avant.
Merci beaucoup ! Une question : les noms des champs ne correspondent pas à ceux de la réponse, est-ce parce qu'ils subissent une minification ?
Merci beaucoup ! Une question : les noms des champs ne correspondent pas à ceux de la réponse, est-ce parce qu'ils subissent une minification ?
Oui : https://git.sr.ht/~codegouvfr/codegouvfr-consolidate-data/tree/master/item/src/utils.clj#L43
Décrire les points d'API et les modèles de données actuels Les schémas de données sont ici : https://git.sr.ht/~codegouvfr/codegouvfr-fetch-data/tree/master/schemas/ Mais ces descriptions peuvent être mises plus en avant.
Merci beaucoup ! Une question : les noms des champs ne correspondent pas à ceux de la réponse, est-ce parce qu'ils subissent une minification ?
Voir aussi https://git.sr.ht/~codegouvfr/codegouvfr-consolidate-data/tree/main/item/src/utils.clj#L43
A rediscuter avant dév
Décrire les points d'API et les modèles de données actuels (si pas déjà fait)repos.json
:name
: à garder dans la réponseorganization_name
: à garder ou à déduire de l'url ?platform
: à supprimer de la réponserepository_url
: à garderdescription
: à garderis_fork
: à garder si applicable sur d'autres plateformes que githubis_archived
: à garder tel quel ou à fusionner avec un champis_empty
dans un nouveau champis_experimental
last_update
: à garderstars_count
: à garder (quand applicable)forks_count
: à supprimer car seulement sur github ?license
: à garderlanguage
: à garderis_esr
: comment est-il calculé ?is_lib
: à supprimer (cf.type
)is_contrib
: à supprimeris_publiccode
: à compléter avec d'autres fichiers (par exempleREADME
,CONTRIBUTING
) ?reuses
: à supprimerid
?administrations
(champ multiple)version
oulatest_release
oulatest_tag
vitality
dont la valeur est calculée à partir de TBD (cf. https://github.com/italia/publiccode-crawler/blob/main/vitality-ranges.yml)status
dont la valeur (Concept, Alpha, Beta, RC, Stable) est calculée à partir du numéro de version (cf. SemVer) : à calculer côté back ou front ?type
dont la valeur correspond à TBD (champ multiple) : ce champ peut-il être déduit automatiquement ou rempli par l'utilisateur dans la future BDD ? Oui pour les lib, quid des autres types (logiciels, API, algos, etc.) ?sill_id
: ce champ doit-il être rempli automatiquement côté back ou front ?homepage
topics
software_heritage_url
topics
)stats