Skip to content

Releases ​

Een nieuwe versie van dcr-components en cds-tokens publiceren

Een release loopt volledig via Azure DevOps: je start de release, reviewt de release-PR en merget die. Je versioneert of publiceert nooit lokaal. Deze pagina is de enige bron voor het releaseproces; andere documentatie verwijst hiernaar.

1. Dagelijks werk: de PR-titel telt ​

  • Werk op een branch en commit zoals je wil. WIP-commits zijn prima.
  • PR's naar develop worden gesquasht: de PR-titel wordt de commit op develop (Azure zet er Merged PR 123: voor). Die commit bepaalt de volgende versie en de regel in de changelog. De link naar de PR komt automatisch in de changelog.
  • De PR-titel moet daarom een conventional commit zijn: type(scope): beschrijving, bv. fix(dcr-components): {dcr-button} herstel de focus-ring. Een check in de PR-build (commitlint: tools/release/check-pr-title.mjs, config in commitlint.config.mjs) weigert andere titels en legt uit waarom.

De afspraken voor scope, entiteit en beschrijving staan in Conventional Commits.

Type en versie ​

TypeVersieChangelog
featminorja
fix, perfpatchja
style (visuele wijzigingen)patchja
docs, refactorgeen releaseja
test, build, cigeen releasenee
choregeen releasenee
! na de scope, bv. feat(dcr-components)!: …major (breaking change)ja

docs en refactor starten zelf geen release, maar verschijnen wel in de changelog van de volgende release.

2. Een release maken ​

Een release maak je wanneer het team dat wil, bv. als een consumer een wijziging nodig heeft of op het einde van de sprint. Start ze op een van deze manieren:

  • Terminal: npm run release vanuit de root van de repo. Nodig: de Azure CLI met de azure-devops-extensie, eenmalig aangemeld met az login.
  • Azure DevOps: Pipelines β†’ die-core-release β†’ Run pipeline, branch develop, Versie auto.
  • die-launcher: Release of Release (dry-run) in het β‹―-menu van DIE CORE Β· COMPONENTS.

Opties voor npm run release -- <optie>:

OptieEffect
--dry-runtoont de versies en de changelog, maakt geen PR
--version=major, minor, patch, premajor, …, 1.2.3forceert een versie
--preid=betaprerelease, bv. 1.3.0-beta.0 onder npm dist-tag beta
--no-openopent de release-PR niet in de browser
--work-item=12345koppelt een work item aan de release-PR (policy op develop)

3. Wat er gebeurt ​

  1. Release-PR voorbereiden (azure-pipelines/release.yml, tools/release/prepare.mjs)
    • nx release bepaalt per lib de nieuwe versie uit de conventional commits sinds de laatste git-tag van die lib ({project}/v{version}).
    • Alleen dcr-components en cds-tokens worden gereleased, elk met een eigen versie. Een lib zonder relevante wijzigingen krijgt geen release.
    • De pipeline schrijft package.json, package-lock.json en CHANGELOG.md en opent een release-PR met als titel chore(release): publish ….
  2. Reviewen en mergen: kijk de changelog na in de release-PR, pas hem daar aan indien nodig en klik Complete.
  3. Publiceren (tools/release/publish.mjs): de merge start de publish. Elke versie die nog niet op de feed staat, wordt gepubliceerd: een stabiele versie onder latest, een prerelease onder zijn preid als dist-tag. Pas na een geslaagde publish wordt getagd, zodat tags en feed altijd overeenkomen.
  4. Deployen: op develop bouwt een stabiele dcr-components-release ook Storybook en de docs-site. Classic Release 47 deployt ze naar docs.kabas.be/storybook en docs.kabas.be/design. De docs deployen ook wanneer libs/cds-docs wijzigt op develop.

4. Meldingen in Slack ​

De pipeline post twee berichten:

  • Release-PR klaar: de versies, de belangrijkste changelog-regels en een link naar de PR om te reviewen.
  • Gepubliceerd: per pakket de versie, de dist-tag en de changelog-regels zoals ze gemerged zijn (met de aanpassingen uit de release-PR), en een link naar de volledige changelog. Bij een stabiele dcr-components-release ook de links naar Storybook en docs.

Elk bericht gaat naar een Slack Incoming Webhook in een geheime pipeline-variabele van die-core-release, elk naar zijn eigen kanaal:

BerichtVariabeleNiet gezet
Release-PR klaarSLACK_RELEASE_PR_WEBHOOK_URLnaar SLACK_WEBHOOK_URL
GepubliceerdSLACK_RELEASED_WEBHOOK_URLnaar SLACK_WEBHOOK_URL

Zonder webhook wordt er niets gepost; een mislukt bericht laat de release nooit falen.

5. Regels ​

  • Stabiele versies komen enkel van develop. Elke andere branch kan alleen prereleases maken.
  • Een nieuwe release wordt geweigerd zolang de vorige gemergde release-PR nog niet gepubliceerd en getagd is.
  • cds-tokens is een peerDependency van dcr-components. Krijgt cds-tokens een nieuwe versie, dan volgt de peer-range in dcr-components automatisch en krijgt dcr-components een patch.
  • Pas een CHANGELOG.md nooit aan buiten de release-PR. CHANGELOG.md-bestanden worden niet door prettier geformatteerd.
  • Niet meer gebruiken: release/*-branches, lokaal versioneren of publiceren (nx release, nx release publish) en tools/src/release-branch.sh.