semver · JohnTitor · Mar 9, 2026 · Mar 9, 2026
diff --git a/lang/nl/index.md b/lang/nl/index.md
@@ -11,9 +11,9 @@ Samenvatting
 
 Bij een versienummer in de vorm MAJOR.MINOR.PATCH, worden de individuele elementen als volgt verhoogd:
 
-1. MAJOR wordt verhoogd bij incompatibele API-wijzigingen.
-1. MINOR wordt verhoogd bij het toevoegen van functionaliteit die backward compatibel is.
-1. PATCH wordt verhoogd bij backward compatibele bugfixes.
+1. MAJOR wordt verhoogd bij _incompatible_ API-wijzigingen.
+1. MINOR wordt verhoogd bij het toevoegen van functionaliteit die _backwards compatible_ is.
+1. PATCH wordt verhoogd bij backwards _compatible_ bugfixes.
 
 Er zijn aanvullende labels beschikbaar voor prerelease en build-metadata om toe te voegen aan het MAJOR.MINOR.PATCH-formaat.
 
@@ -22,16 +22,16 @@ Introductie
 
 In de wereld van softwarebeheer bestaat er een gevreesde plek genaamd "dependency hell" oftewel de "hel van afhankelijkheden". Hoe groter een systeem wordt en hoe meer packages er worden geïntegreerd in de software, des te aannemelijker is het dat je op een zekere dag belandt op deze mistroostige plek.
 
-Het uitbrengen van een nieuwe packageversie kan al snel een nachtmerrie worden als systemen te maken hebben met een hoop afhankelijkheden. Als de afhankelijkheden te strikt gespecificeerd zijn, ontstaat het gevaar op "version lock": het is dan niet meer mogelijk om een package te upgraden zonder dat alle afhankelijke packages ook een versie verhoogd moeten worden. Als de afhankelijkheden te losjes zijn gespecificeerd, zul je onvermijdelijk worden gebeten door het fenomeen versievermenging: de verwachting dat er meer compatibiliteit is met toekomstige versies dan je redelijkerwijs mag verwachten. Je bevindt je in de hel van afhankelijkheden wanneer "version lock" en/of versievermenging zodanig in de weg zitten dat je project niet makkelijk en veilig kan worden voortgezet.
+Het uitbrengen van een nieuwe packageversie kan al snel een nachtmerrie worden als systemen te maken hebben met een hoop afhankelijkheden. Als de afhankelijkheden te strikt gespecificeerd zijn, ontstaat het gevaar op "version lock": het is dan niet meer mogelijk om een package te upgraden zonder dat alle afhankelijke packages ook een versie verhoogd moeten worden. Als de afhankelijkheden te losjes zijn gespecificeerd, zul je onvermijdelijk worden gebeten door het fenomeen versievermenging: de verwachting dat er meer _compatibility_ is met toekomstige versies dan je redelijkerwijs mag verwachten. Je bevindt je in de hel van afhankelijkheden wanneer "version lock" en/of versievermenging zodanig in de weg zitten dat je project niet makkelijk en veilig kan worden voortgezet.
 
-Als oplossing voor dit probleem stellen we een simpele set van regels en voorwaarden voor die beschrijven hoe versienummers toegewezen en verhoogd worden. Deze regels zijn gebaseerd op, maar niet noodzakelijk beperkt tot, reeds bestaande en wijdverspreide gebruiken in zowel gesloten als opensource-software. Om dit systeem succesvol te laten zijn, is het als eerste nodig om je API publiek te declareren. Of deze nu bestaat uit documentatie of wordt afgedwongen door de code zelf maakt niet uit: het belangrijkste is dat de API duidelijk en exact is. Zodra je je publieke API geïdentificeerd hebt, worden wijzigingen gecommuniceerd met specifieke verhogingen in het versienummer. Gebruik een versieformaat van X.Y.Z (Major.Minor.Patch). Bugfixes zonder effect op de API verhogen de patchversie, toevoegingen en wijzigingen aan de API die backward compatibel zijn verhogen de minorversie en wijzigingen aan de API die niet backward compatibel zijn verhogen de majorversie.
+Als oplossing voor dit probleem stellen we een simpele set van regels en voorwaarden voor die beschrijven hoe versienummers toegewezen en verhoogd worden. Deze regels zijn gebaseerd op, maar niet noodzakelijk beperkt tot, reeds bestaande en wijdverspreide gebruiken in zowel gesloten als opensource-software. Om dit systeem succesvol te laten zijn, is het als eerste nodig om je API publiek te declareren. Of deze nu bestaat uit documentatie of wordt afgedwongen door de code zelf maakt niet uit: het belangrijkste is dat de API duidelijk en exact is. Zodra je je publieke API geïdentificeerd hebt, worden wijzigingen gecommuniceerd met specifieke verhogingen in het versienummer. Gebruik een versieformaat van X.Y.Z (Major.Minor.Patch). Bugfixes zonder effect op de API verhogen de patchversie, toevoegingen en wijzigingen aan de API die backwards compatible zijn verhogen de minorversie en wijzigingen aan de API die niet backwards compatible zijn verhogen de majorversie.
 
 We noemen dit systeem "Semantisch Versioneren", waarmee versienummers en de manier waarop ze veranderen en verhoogd worden duiding geven over de onderliggende code en wat er is aangepast tussen de verschillende versies.
 
 Specificatie Semantisch Versioneren (SemVer)
 ------------------------------------------
 
-De termen "MOET/VERPLICHT" ("MUST"), "MAG NIET" ("MUST NOT"), "VEREIST/NOODZAKELIJK" ("REQUIRED"), "ZAL/MOET" ("SHALL"), "ZAL NIET/MAG NIET" ("SHALL NOT"), "ZOU MOETEN/AANBEVOLEN" ("SHOULD/RECOMMENDED"), "ZOU NIET MOETEN" ("SHOULD NOT"), "MAG" ("MAY"), en "OPTIONEEL/VRIJBLIJVEND" ("OPTIONAL") in dit document dienen geïnterpreteerd te worden zoals beschreven in [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119) of in de [Nederlandse interpretatie](https://github.com/Stichting-CROW/respec/wiki/RFC-2119-Nederlands) ervan.
+De termen "MOET/VERPLICHT" ("MUST"), "MAG NIET" ("MUST NOT"), "VEREIST/NOODZAKELIJK" ("REQUIRED"), "ZAL/MOET" ("SHALL"), "ZAL NIET/MAG NIET" ("SHALL NOT"), "ZOU MOETEN/AANBEVOLEN" ("SHOULD/RECOMMENDED"), "ZOU NIET MOETEN" ("SHOULD NOT"), "MAG" ("MAY"), en "OPTIONEEL/VRIJBLIJVEND" ("OPTIONAL") in dit document dienen geïnterpreteerd te worden zoals beschreven in [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119).
 
 1. Software die gebruikmaakt van Semantisch Versioneren MOET een publieke API declareren. Deze API kan worden gepubliceerd in de code of strikt uit documentatie bestaan. Ongeacht de vorm is het de bedoeling dat deze nauwkeurig en uitgebreid ZOU MOETEN zijn.
 
@@ -43,11 +43,11 @@ De termen "MOET/VERPLICHT" ("MUST"), "MAG NIET" ("MUST NOT"), "VEREIST/NOODZAKEL
 
 1. Versie 1.0.0 definieert de publieke API. De manier waarop het versienummer wordt verhoogd na deze release is afhankelijk van de publieke API en hoe deze verandert.
 
-1. Patchversie Z (x.y.Z \| x > 0) MOET worden verhoogd als wijzigingen zijn doorgevoerd die backward compatibel zijn. De definitie van een bugfix is een interne wijziging die foutief gedrag corrigeert.
+1. Patchversie Z (x.y.Z \| x > 0) MOET worden verhoogd als wijzigingen zijn doorgevoerd die backwards compatible zijn. De definitie van een bugfix is een interne wijziging die foutief gedrag corrigeert.
 
-1. Minorversie Y (x.Y.z \| x > 0) MOET worden verhoogd als nieuwe, backward compatibele wijzigingen worden gedaan aan de publieke API. Het MOET worden verhoogd op het moment dat publieke-API-functionaliteit wordt uitgefaseerd. Het MAG worden verhoogd als substantiële nieuwe functionaliteit of verbeteringen worden doorgevoerd in de afgeschermde code. Het MAG ook wijzigingen van niveau patch bevatten. De patchversie MOET op 0 worden teruggezet wanneer de minorversie is verhoogd.
+1. Minorversie Y (x.Y.z \| x > 0) MOET worden verhoogd als nieuwe, backwards compatible wijzigingen worden gedaan aan de publieke API. Het MOET worden verhoogd op het moment dat publieke-API-functionaliteit wordt uitgefaseerd. Het MAG worden verhoogd als substantiële nieuwe functionaliteit of verbeteringen worden doorgevoerd in de afgeschermde code. Het MAG ook wijzigingen van niveau patch bevatten. De patchversie MOET op 0 worden teruggezet wanneer de minorversie is verhoogd.
 
-1. Majorversie X (X.y.z \| X > 0) MOET worden verhoogd als wijzigingen worden doorgevoerd die backward incompatibel zijn met de publieke API. Het MAG ook wijzigingen van niveau minor en patch bevatten. De patch- en minorversie MOETEN op 0 worden teruggezet wanneer de majorversie is verhoogd.
+1. Majorversie X (X.y.z \| X > 0) MOET worden verhoogd als wijzigingen worden doorgevoerd die _backwards incompatible_ zijn met de publieke API. Het MAG ook wijzigingen van niveau minor en patch bevatten. De patch- en minorversie MOETEN op 0 worden teruggezet wanneer de majorversie is verhoogd.
 
 1. Een prerelease-versie MAG worden aangeduid met de toevoeging van een koppelteken en een serie van puntgescheiden id's direct volgend op de patchversie. Id's MOETEN slechts bestaan uit alfanumerieke ASCII-karakters en -koppeltekens [0-9A-Za-z-]. Id's MOGEN NIET leeg zijn. Voorloopnullen MOGEN NIET aanwezig zijn in numerieke id's. Prerelease-versies hebben een lagere prioriteit dan de bijbehorende reguliere versie. Een prerelease-versie impliceert instabiel te zijn en voldoet mogelijk niet aan de voorgenomen compatibiliteitseisen zoals aangeduid bij de bijbehorende reguliere versie. Voorbeelden: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92, 1.0.0-x-y-z.\-\-.
 
@@ -142,7 +142,7 @@ Waarom semantisch versioneren?
 
 Dit is geen nieuw of revolutionair idee, waarschijnlijk gebruik je al iets wat hier erg op lijkt. En daar gaat het nu juist om: dat is niet goed genoeg. Zonder je aan een formele specificatie te houden zijn versienummers in essentie nutteloos voor afhankelijkheidsbeheer. Door de bovenstaande ideeën een naam te geven en ze helder te definiëren, is het makkelijker om je bedoelingen over te brengen aan de gebruikers van je software. Pas als deze bedoelingen helder en flexibel (maar niet te flexibel) zijn, kunnen eindelijk specificaties over afhankelijkheid worden gemaakt.
 
-Een eenvoudig voorbeeld toont aan hoe Semantisch Versioneren voorgoed afrekent met de hel van afhankelijkheden. Denk aan een softwarebibliotheek genaamd "Brandweerwagen". Deze heeft een SemVer-package genaamd "Ladder" nodig. Op het moment dat Brandweerwagen uitgebracht wordt, zit Ladder op versie 3.1.0. Omdat Brandweerwagen functionaliteit gebruikt die is geïntroduceerd in versie 3.1.0, kun je veilig vastleggen dat de afhankelijkheid van Ladder groter dan of gelijk is aan 3.1.0 maar kleiner dan 4.0.0. Als Ladder-versie 3.1.1 en 3.2.0 beschikbaar komen, kunnen deze worden gepubliceerd naar het package-beheersysteem wetend dat ze compatibel zijn met huidige, afhankelijke software.
+Een eenvoudig voorbeeld toont aan hoe Semantisch Versioneren voorgoed afrekent met de hel van afhankelijkheden. Denk aan een softwarebibliotheek genaamd "Brandweerwagen". Deze heeft een SemVer-package genaamd "Ladder" nodig. Op het moment dat Brandweerwagen uitgebracht wordt, zit Ladder op versie 3.1.0. Omdat Brandweerwagen functionaliteit gebruikt die is geïntroduceerd in versie 3.1.0, kun je veilig vastleggen dat de afhankelijkheid van Ladder groter dan of gelijk is aan 3.1.0 maar kleiner dan 4.0.0. Als Ladder-versie 3.1.1 en 3.2.0 beschikbaar komen, kunnen deze worden gepubliceerd naar het package-beheersysteem wetend dat ze compatible zijn met huidige, afhankelijke software.
 
 Als een verantwoordelijke ontwikkelaar wil je natuurlijk nagaan dat alle package-upgrades functioneren zoals beschreven. De echte wereld is turbulent; daar kunnen we niets aan doen anders dan waakzaam zijn. Je kunt Semantisch Versioneren gebruiken als een verstandige en logische manier om packages uit te brengen en bij te werken, zonder nieuwe versies van afhankelijke packages uit te moeten brengen. Dat bespaart tijd en gedoe.
 
@@ -157,29 +157,29 @@ Het makkelijkst is om de release van de eerste ontwikkelfase te starten met 0.1.
 
 ### Hoe weet ik wanneer ik versie 1.0.0 kan uitbrengen?
 
-Als de software reeds in productie gebruikt wordt, is deze waarschijnlijk al versie 1.0.0. Als je een stabiele API hebt waar gebruikers van afhankelijk zijn, dan dien je op versie 1.0.0 te zitten. Bij zorgen over backward compatibiliteit had je waarschijnlijk al op versie 1.0.0 moeten zitten.
+Als de software reeds in productie gebruikt wordt, is deze waarschijnlijk al versie 1.0.0. Als je een stabiele API hebt waar gebruikers van afhankelijk zijn, dan dien je op versie 1.0.0 te zitten. Bij zorgen over backwards compatibility had je waarschijnlijk al op versie 1.0.0 moeten zitten.
 
 ### Werkt dit niet ontmoedigend voor snel ontwikkelen en snelle iteraties?
 
 Bij majorversie nul draait het om snelle ontwikkeling. Als je de API dagelijks wijzigt, zou je nog op versie 0.y.z moeten zitten of op een aparte ontwikkelbranch voor de volgende majorversie.
 
-### Als zelfs kleine backward incompatibele wijzigingen aan de publieke API zorgen voor een verhoging van de majorversie, zit ik dan niet binnen afzienbare tijd op versie 42.0.0?
+### Als zelfs kleine backwards incompatible wijzigingen aan de publieke API zorgen voor een verhoging van de majorversie, zit ik dan niet binnen afzienbare tijd op versie 42.0.0?
 
-Het gaat hier om verantwoordelijk ontwikkelen en voortschrijdend inzicht. Backward incompatibele wijzigingen dienen niet licht opgevat te worden als het om software gaat waar veel van afhankelijk is. De ontwikkelkosten voor een upgrade kunnen significant zijn. Een majorversie verhogen voor het uitbrengen van backward incompatibele wijzigingen, betekent dat je moet nadenken over de impact van de wijzigingen en daarbij de kosten en baten in overweging moet nemen.
+Het gaat hier om verantwoordelijk ontwikkelen en voortschrijdend inzicht. Backwards incompatible wijzigingen dienen niet licht opgevat te worden als het om software gaat waar veel van afhankelijk is. De ontwikkelkosten voor een upgrade kunnen significant zijn. Een majorversie verhogen voor het uitbrengen van backwards incompatible wijzigingen, betekent dat je moet nadenken over de impact van de wijzigingen en daarbij de kosten en baten in overweging moet nemen.
 
 ### Het is veel te veel werk om de volledige publieke API te documenteren!
 
 Het is je verantwoordelijkheid als professioneel ontwikkelaar om software die door anderen gebruikt wordt adequaat te documenteren. Een essentieel onderdeel van een efficiënt softwareproject is om de complexiteit beheersbaar te houden, wat bijzonder lastig wordt als niemand weet hoe je software gebruikt moet worden en welke methoden veilig zijn aan te roepen. Op de lange duur zorgen Semantisch Versioneren en het hameren op een goed gedocumenteerde API ervoor dat de zaken soepel lopen.
 
-### Wat als ik per ongeluk een backward incompatibele wijziging uitbreng als een minorversie?
+### Wat als ik per ongeluk een backwards incompatible wijziging uitbreng als een minorversie?
 
-Als je je realiseert dat je de regels van Semantisch Versioneren overtreden hebt, breng dan zo snel mogelijk een nieuwe minorversie uit die het probleem oplost en de backward incompatibiliteit repareert. Zelfs onder deze omstandigheden is het onacceptabel dat reeds uitgebrachte versies gewijzigd worden. Indien toepasselijk, documenteer de foute versie en informeer je gebruikers over het probleem zodat ze er rekening mee kunnen houden.
+Als je je realiseert dat je de regels van Semantisch Versioneren overtreden hebt, breng dan zo snel mogelijk een nieuwe minorversie uit die het probleem oplost en de _backwards incompatibility_ repareert. Zelfs onder deze omstandigheden is het onacceptabel dat reeds uitgebrachte versies gewijzigd worden. Indien toepasselijk, documenteer de foute versie en informeer je gebruikers over het probleem zodat ze er rekening mee kunnen houden.
 
 ### Wat moet ik doen als ik mijn eigen afhankelijkheden bijwerk zonder wijzigingen aan de publieke API?
 
-Dit wordt beschouwd als compatibel omdat het geen effect heeft op de publieke API. Software die expliciet afhankelijk is van dezelfde afhankelijkheden als jouw package, dient eigen specificaties over deze afhankelijkheden te hebben waarbij de maker conflicten zal opmerken. Bepalen of de wijziging van het niveau patch of minor is, hangt af van het feit of je afhankelijkheden zijn bijgewerkt om een bug op te lossen of om nieuwe functionaliteit uit te brengen. Voor het tweede is er meestal nieuwe code toegevoegd, wat het zonder twijfel een minorwijziging maakt.
+Dit wordt beschouwd als compatible omdat het geen effect heeft op de publieke API. Software die expliciet afhankelijk is van dezelfde afhankelijkheden als jouw package, dient eigen specificaties over deze afhankelijkheden te hebben waarbij de maker conflicten zal opmerken. Bepalen of de wijziging van het niveau patch of minor is, hangt af van het feit of je afhankelijkheden zijn bijgewerkt om een bug op te lossen of om nieuwe functionaliteit uit te brengen. Voor het tweede is er meestal nieuwe code toegevoegd, wat het zonder twijfel een minorwijziging maakt.
 
-### Wat als ik per ongeluk de publieke API aanpas op een manier die niet strookt met de wijziging in het versienummer (bijvoorbeeld: de code introduceert een backward incompatibele majorwijziging in een patchrelease)?
+### Wat als ik per ongeluk de publieke API aanpas op een manier die niet strookt met de wijziging in het versienummer (bijvoorbeeld: de code introduceert een backwards incompatible majorwijziging in een patchrelease)?
 
 Gebruik je gezond verstand. Bij een groot publiek dat veel hinder ondervindt als het gedrag van de publieke API weer wordt aangepast, kan het de beste keus zijn om een majorversie uit te brengen ook al is de wijziging eigenlijk een patch. Onthoud dat Semantisch Versioneren vooral gaat over het geven van betekenis aan de manier waarop het versienummer verandert. Als deze wijzigingen belangrijk zijn voor je gebruikers, zet dan het versienummer in om ze hierover te informeren.
 
@@ -205,7 +205,7 @@ Zie ook: <https://regex101.com/r/Ly7O1x/3/>
 ^(?P<major>0|[1-9]\d*)\.(?P<minor>0|[1-9]\d*)\.(?P<patch>0|[1-9]\d*)(?:-(?P<prerelease>(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+(?P<buildmetadata>[0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$
 ```
 
-En een met *numbered capture groups* (dus cg1 = major, cg2 = minor, cg3 = patch, cg4 = prerelease and cg5 = build-metadata) die compatibel is met ECMA Script (JavaScript), PCRE (Perl Compatible Regular Expressions,zoals Perl, PHP and R), Python en Go.
+En een met *numbered capture groups* (dus cg1 = major, cg2 = minor, cg3 = patch, cg4 = prerelease and cg5 = build-metadata) die compatible is met ECMA Script (JavaScript), PCRE (Perl Compatible Regular Expressions,zoals Perl, PHP and R), Python en Go.
 
 Zie ook: <https://regex101.com/r/vkijKf/1/>