Déclarer la section
Le type de section `changelog` — où vit le fichier, et les deux politiques auxquelles il répond.
Un historique des versions est une section générée : une source nomme le fichier et le type qui le lit, et les pages en découlent.
export default defineAppConfig({
duxt: {
sources: [
{
path: 'docs',
generated: [
{
type: 'changelog',
path: 'CHANGELOG.md',
label: 'Releases'
}
]
}
]
}
})
Les champs qu’une déclaration prend sont les mêmes pour tous les types et se
trouvent dans Sources. changelog nomme une option propre —
granularity — et répond aux deux politiques
ci-dessous.
Versionnage
Global. Un historique, lu depuis la version par défaut, servi à une URL neutre vis-à-vis des versions, sélecteur supprimé.
Un journal des versions n’est pas un document par version qui mentionne d’autres
versions — c’est la liste des versions. En construire une copie par version
publierait le même fichier sous trois URL, chacune privée des versions venues
ensuite, et un lecteur tombé sur v1 s’entendrait dire que le projet s’est arrêté
là.
Localisation
L’original, dans toutes les langues. Une collection, construite depuis la langue par défaut.
Un journal des versions est écrit une fois, par l’outil de release, dans la langue
où le projet commite. Rien n’y est propre à une langue : un site localisé sert donc
l’original et le dit avec le
bandeau de traduction qu’il dessine déjà pour une page
non traduite. La table locales de la déclaration n’est lue que par les types
per-locale et ne fait rien ici.
Où va l’entrée
navigation: 'sections' est la valeur par défaut et place l’entrée dans la rangée
des sections — les parties de premier niveau de la documentation.
Un journal des versions n’en est souvent pas une : c’est une chose que le projet a
à côté de sa documentation, non une partie de celle-ci.
navigation: 'navigation' déplace l’entrée dans la première rangée, étroite, et
false ne la place nulle part et laisse le site la lier.
{
type: 'changelog',
path: 'CHANGELOG.md',
label: 'Releases',
navigation: 'navigation'
}
Écrire l’entrée vous-même dans navigation la garde là où vous l’avez mise — le
build laisse tranquille une section qu’il trouve déjà dans la rangée, au lieu de
l’ajouter à la fin. Ce qui compte, car ajoutée veut dire dernière, et après Crédits
n’est pas la place d’un journal des versions.
Le flux
duxt.feed.path nomme la section depuis laquelle /rss.xml est construit, et un
historique des versions est ce pour quoi il a été écrit : chaque page de version
porte la date propre de cette version, et une version est une chose qui s’est
produite — ce qu’une page de référence modifiée n’est pas.
feed: { path: '/releases', title: 'mon projet — versions' }
Éteint tant que la clé n’est pas posée. Seule la version par défaut de chaque
source contribue, un site versionné ne répète donc pas chaque entrée une fois par
version — et avec une section global il n’y a de toute façon qu’un historique.
Voir Configuration et
/rss.xml.
Quand le fichier ne peut pas être lu
Un fichier local absent fait échouer le build au chargement de la configuration, comme pour tout type. Ce que le fichier ne dit pas tout à fait — un titre qui ressemble à une version mais ne se lit pas comme telle — est en revanche un avertissement dans le rapport de build ; voir Ce qui est lu et Ce que le build vérifie.