Iterative Versioning - 2019.01.02 - Nederlands
Publicationdate: 2019-01-21T12:01:53+01:00Versienummers
TL;DR jaar.sprint-of-productierelease.bouwpoging(-TOEVOEGING)
De versienummering die gebruikt wordt kent het volgende formaat: x.y.z(-TOEVOEGING), waarbij de letters de volgende waarde representeren.
| Letter | Betekenis | Toelichting | |
| x | Jaar | Waar de x ook wel wordt gebruikt om een major release aan te duiden, is het logischer om het jaartal te gebruiken, omdat je dan samen met het sprintnummer kunt herleiden wanneer deze release heeft plaatsgevonden. | |
| y | Sprint / Productierelease | Het heeft zin om na elke sprint dit versienummer op te hogen, omdat je dan ook met terugwerkende kracht altijd kunt herleiden welke versie vorige keer live heeft gestaan. | |
| z | Bouwpoging | In verband met iteratie is het zinnig dit nummer elke keer op te hogen als je een release maakt die op één van de (o)TAP omgevingen komt te staan. | |
| (-TOEVOEGING) | Aanduiding | De terminologie snapshot is ooit in het leven geroepen om aan te geven dat de huidige build een snapshot is van een willekeurig moment en dus waarschijnlijk geen productiewaardige buildartifact oplevert. Dit wordt gebruikt in projecten waar de code kan worden uitgecheckt door derden. De toevoeging SNAPSHOT duidt dan op dat er nog changes in deze release kunnen komen in de toekomst. Bij software die binnen één projectteam gebruikt wordt is het gebruik hiervan dus niet altijd nodig. Je zou deze toevoeging kunnen gebruiken om releases aan te duiden die gebruikt worden om een specifieke functionaliteit te testen. |
Versies en releases - flow
TL;DR Git flow
Hieronder de flow van hoe de versienummering zich verhoudt tot het release proces.
Wanneer gebruik je Iterative Versioning?
TL;DR geen eindgebruikers.
Waarom geen semantic versioning?
Dit in tegenstelling tot het meer gebruikelijke semantic versioning. Reden om deze standaard achter ons te laten is dat in deze manier versioneren uitgegaan wordt dat je versies bijhoudt met als doel de uiteindelijk eindgebruiker te kunnen informeren over al dan niet backwards compatibility. Omdat de Hippo repo geen eindgebruikers kent en dus de versienummers alleen betekenis hoeven hebben voor de ontwikkelaars die aan het project werken, is semantic versioning hier dus geen toegevoegde waarde.
Specificatie
Er is getracht een directe vertaling in het Nederlands te hanteren van MUST (MOET(EN)), MAY (MOGEN), MUST NOT (MAG NIET), conform de definitie RFC 2119.
Een versienummer MOET de vorm x.y.z hanteren, waar x, y en z non-negatieve integers zijn en MOGEN leading zero's bevatten. X is het jaartal, Y de sprint of de productierelease en Z de iteratie. Elk element MOET numeriek ophogen, bijvoorbeeld: 2019.01.01 -> 2019.01.02 -> 2019.01.03.
Wanneer een package is gereleaset, MAG de inhoud NIET wijzigen. Alle wijzigingen MOETEN gereleaset worden onder een nieuwe versie.
Versie X.01.Z definieert de eerste productierelease, waarbij X het jaartal van de release is en Z de hoeveelste iteratie dit is.
Sprint of productierelease Y (x.Y.z) MOET ophogen wanneer ófwel een nieuwe sprint begonnen wordt, volgens Agile methodiek Scrum ófwel wanneer een productierelease heeft plaatsgevonden. Nadat sprint of productierelease Y is opgehoogd, begint iteratie Z (x.y.Z) op 01.
Jaartal X (X.y.z) MOET opgehoogd worden als een nieuw kalenderjaar aanbreekt. Sprint of productierelease Y EN iteratie Z beginnen beide op 01, wanneer jaartal X ophoogt.
Een pre-release versie MAG toegelicht worden door een koppelteken (verbindingsstreepje) toe te voegen gevolgd door een serie ASCII alphanumerieke hoofdletters, cijfers en koppeltekens [0-9A-Z-]. Pre-release versies hebben een lagere prioriteit dan de bijbehorende normale versie. Een pre-release versie geeft aan dat de versie onstabiel is en mogelijk niet aan de gewenste functionaliteiten, compatibiliteit en of requirements voldoet, zoals die geïmpliceerd worden door de bijbehorende normale versie. Bijvoorbeeld 2019.01.01-TEST, 2019.01.01-ALPHA, 2019.01.01-TICKET-NUMMER-01.
Build metadata MAG toegevoegd worden door een plusteken en een serie door punten gescheiden identifiers direct achter de iteratie (Z) of pre-release versie te plaatsen. Identifiers MOETEN alleen bestaan uit ASCII alphanumerieken en koppeltekens [0-9A-Za-z-].Identifiers MOGEN NIET leeg zijn. Build metadata ZOU genegeerd moeten worden wanneer je de prioriteit van de versie vaststelt. Twee versies die alleen verschillen in metadata, hebben dus dezelfde prioriteit. Voorbeelden: 2019.01.01-ALPHA+001, 2019.01.01+201901011130, 2019.01.01-BETA+exp.sha.1567f99.
Prioriteit (volgordelijkheid) refereert naar hoe versies zich tot elkaar verhouden, wanneer ze op volgorde worden gesteld. Prioriteit MOET berekend worden door de versie in jaar, sprint of productierelease, iteratie en pre-release identifiers in die volgorde de splitsen (build metadata telt niet mee voor prioritering). Prioriteit wordt bepaald door het eerste verschil wanneer je iedere identifier van links naar de rechts vergelijkt: jaar, sprint of productierelease, iteratie worden altijd numeriek vergeleken. Bijvoorbeeld 2019.01.01 < 2020.01.01 < 2020.02.01 < 2020.02.02. Wanneer jaar, sprint of productierelease en iteratie allemaal gelijk zijn, heeft een pre-release lagere prioriteit dan de bijbehorende normale versie. Bijvoorbeeld 2019.01.01-ALPHA < 2019.01.01. Prioriteit voor twee pre-release versies met hetzelfde jaar, sprint of productierelease en iteratie MOETEN onderscheiden worden de door koppelteken gescheiden identifiers van links naar rechts met elkaar te vergelijken totdat er een verschil is gevonden. Numerieke identifiers worden numeriek vergeleken. Alphanumerieke identiefiers worden lexicaal vergeleken in ASCII volgorde. Numerieke identiefiers hebben altijd lagere prioriteit dan niet-numerieke identiefiers. Een grotere set pre-release fields heeft een hogere prioriteit dan een kleinere set, als alle voorgaande identifiers gelijk zijn. Bijvoorbeeld: 2019.01.01-ALPHA < 2019.01.01-ALPHA-1 < 2019.01.01-ALPHA-BETA < 2019.01.01-BETA < 2019.01.01-BETA-2 < 2019.01.01-BETA-11 < 2019.01.01-RC-1 < 2019.01.01.