Computable.nl
  • Thema’s
    • Carrière
    • Innovatie & Transformatie
    • Cloud & Infrastructuur
    • Data & AI
    • Governance & Privacy
    • Security & Awareness
    • Software & Development
    • Werkplek & Beheer
  • Sectoren
    • Channel
    • Financiële dienstverlening
    • Logistiek
    • Onderwijs
    • Overheid
    • Zorg
  • Computable Awards
    • Overzicht
    • Nieuws
    • Winnaars
    • Partner worden
  • Vacatures
    • Vacatures bekijken
    • Vacatures plaatsen
  • Bedrijven
    • Profielen
    • Producten & Diensten
  • Kennisbank
  • Nieuwsbrief

Semantiek in versienummers

28 februari 2019 - 09:236 minuten leestijdOpinieInnovatie & TransformatieAppleMicrosoft
Jens Kooij
Jens Kooij

Wie met code werkt, kent het fenomeen: wanneer is een wijziging groot genoeg om het ophogen van een versienummer te rechtvaardigen. Is dit een minor change? Of toch meer een bugfix? Er zijn natuurlijk handvatten beschikbaar. In deze blog bespreken we semantiek in versienummering en presenteer ik mijn eigen variant: iterative versioning.

Allereerst een kleine toelichting van welke versienummeringen er bestaan en in welke situatie ze bruikbaar zijn.

  • Semantic versioning

Een van de bekendste versioneringsschema’s is semantic versioning.  Een duidelijke manier van structureren van je versienummer. Drie cijfers.

  1. De major, wanneer een wijziging niet compatible is met de vorige versies.

  2. De minor, wanneer er nieuwe functionaliteit wordt toegevoegd, die wel compatible is met de huidige major versie.

  3. De patch, voor bugfixes die compatible zijn met vorige minor versies.

Een goed en duidelijk systeem, waarmee je aan de developers die gebruik maken van jouw code om hun software mee te ontwikkelen. Maar wat als er geen developers zijn die jouw code gebruiken, behalve je teamgenoten? Als je bijvoorbeeld aan een product werkt dat publiekelijk gebruikt wordt?

  • Public versioning

Een goed voorbeeld, of eigenlijk niet zo’n goed voorbeeld, van public versioning is Microsoft Windows. In het begin was er logica. Versie 2 volgende op versie 1. Versie drie volgde daarop, maar werd publiek beter bekend na wat patches: Windows 3.11. Daarna ging Microsoft over op een versienummering gebaseerd op het jaar waarin Windows gelanceerd werd. 95, 98, 2000. Begrijpelijker voor consumenten. Echter met de flop van Windows 2000 (of erger nog Millennium Edition), besloten ze wéér van versienummering te veranderen. Met XP was er de eerste Windows versie die na een kwakkelende lancering één van de meest succesvolle versies bleek. Met 13 jaar lang support die eindigde in 2014, was dit een ongekend succes in de Windows serie. Daarna volgde Vista, een minder goed ontvangen versie, gevolgd door 7, 8 en 10, met als opvallend ontbrekende versie 9. Andere bekende versienummeringen zijn die van Android (toetjes en gebak, zoals FroYo, Gingerbread, Donut) of Apple (sinds versie 10 allerlei katachtigen: Cheetah, Tiger, Leopard) en zo zijn er nog meer voorbeelden. Echte logica is hierin niet altijd terug te herkennen, maar deze versienummers hebben dan ook als doel om het product in de markt te zetten. Maar wat als jouw product niet in de markt gezet wordt? Sterker nog, wat als er van jouw product maar één versie tegelijkertijd bestaat, zoals bij een website bijvoorbeeld? Wellicht is het dan een goed idee om eens na te denken over iterative versioning.

  • Iterative versioning

Wanneer je met scrum werkt, een voorbeeld van de vele verschillende agile methodieken die er bestaan, werk je in sprints. Afgebakende tijdsperioden, waarna je productie(waardige) software oplevert. In het geval van websites, zal er uiteindelijk maar één versie op productie terecht komen. Het is in dat geval zinnig om iterative versioning toe te passen.

Hoe werkt het?

De versienummering die gebruikt wordt, kent het volgende formaat: jaar.sprint-of-productierelease.iteratie(-toelichting).

Een korte toelichting:

  • Jaar: het jaar waarin deze productierelease gebouwd werd.

  • Sprint of productierelease: De hoeveelste sprint van dit jaar is dit? Of als je niet in sprints werkt, de hoeveelste productierelease dit is.

  • Iteratie: De hoeveelste bouwpoging dit is.

  • -toelichting: Wanneer je een release maakt die tussentijds bepaalde functionaliteit moet testen. Het toevoegen van een toelichting is gelijk ook een aanduiding dat deze release niet geschikt is voor productie.

Over iteraties

In veel gevallen wordt in professionele omgevingen gebruik gemaakt van een bouwstraat, ook wel bekend als OTAP of DTAP. Een ontwikkel- (of development), test-, acceptatie- en productieomgeving. Wanneer een release naar bijvoorbeeld de testomgeving gaat kunnen hieruit bugs of andere bevindingen komen. Deze wil je verhelpen voordat je naar productie gaat. Iedere keer dat er nieuwe wijzigingen naar een van de omgevingen worden gereleaset, hoog je het iteratienummer op.

Deze manier van versioneren werkt heel goed samen in combinatie met Git Flow, een methodiek die gebruikt kan worden om version control in te richten. Hieronder staat een schematische weergave van hoe dit er aan toe zou kunnen gaan in een ontwikkelproces.

Releases

Hier vind je een vereenvoudigde weergave van hoe je met behulp van de richtlijnen die geschetst worden in het artikel over Git Flow, een release kunt uitbrengen. Nadat de verschillende feature branches zijn gemerged in de develop branche, maak je een release branche aan. Op het moment dat je hier een releasebuild van maakt, tag je de laatste commit met het versienummer. Deze releasebuild deploy je naar test. Soms komen daar bevindingen uit, die doorgang naar de volgende stap in de ontwikkelstraat belemmeren. De ontwikkelaars kunnen deze verhelpen. Daarna maak je een nieuwe releasebuild, hoog je het iteratienummer op en tag je opnieuw de commit waarvan je de release gebouwd hebt. Vervolgens deploy je deze nieuwe build naar test. Geen bevindingen? Op dezelfde manier ga je door naar acceptatie en uiteindelijk productie.

Tips nodig? Varieer en gebruik wat het best past bij jou project en team. Plus maak bekend welke logica er achter een versienummer zit, door bijvoorbeeld een comment op te nemen die refereert naar documentatie waarin dit staat toegelicht of noem het in de readme van je project.

Wanneer gebruik je welke versienummering?

Je kunt je dus afvragen voor wie deze versienummers zijn? Wat mij betreft zijn er dus verschillende doelen die je kunt bereiken met versienummering. Hier vind je drie situaties en de bijbehorende strategie voor versionering.

  • Wordt jouw code gebruikt door andere ontwikkelaars? Bijvoorbeeld als je aan een open source project werkt, of als je software of API’s publiek toegankelijk zijn. Gebruik dan semantic versioning.
  • Is jouw code de basis van een product dat publiekelijk gebruikt wordt? Gebruik dan versienummers die de eindgebruiker laten weten welke versie ze gebruiken.
  • Is jouw team de enige partij die met de software werkt en maak je gebruik van agile methodieken? Gebruik dan iterative versioning.

Welke methode gebruik jij binnen je team? Wat zijn daar de voor- en nadelen van? Zou iterative versioning iets voor jullie zijn? Of waarom juist niet? Laat het weten in de reacties!

Meer over

AgileBesturingssystemenPatchesScrumWindows VistaWindows XP

Deel

    Inschrijven nieuwsbrief Computable

    Door te klikken op inschrijven geef je toestemming aan Jaarbeurs B.V. om je naam en e-mailadres te verwerken voor het verzenden van een of meer mailings namens Computable. Je kunt je toestemming te allen tijde intrekken via de af­meld­func­tie in de nieuwsbrief.
    Wil je weten hoe Jaarbeurs B.V. omgaat met jouw per­soons­ge­ge­vens? Klik dan hier voor ons privacy statement.

    Whitepapers

    Computable.nl

    Slimme connectiviteit: de toekomst van bouwen

    Hoe stoom jij jouw organisatie in de bouw en installatie sector klaar voor de digitale toekomst?

    Computable.nl

    Design Sprints: 4 dagen van idee naar prototype

    Hoe zet je in vier dagen tijd een gevalideerd prototype neer met Design Sprints?

    Computable.nl

    Dit is de weg naar informatietransformatie

    In een wereld waar data en informatie centraal staan, moeten organisaties zich aanpassen aan de digitale toekomst. Informatietransformatie is de sleutel tot het versterken van beveiliging en het bevorderen van efficiëntie.

    Meer lezen

    ActueelCarrière

    Groningers verkopen crypto-platform Deribit voor 2,9 miljard dollar

    Quantum
    ActueelCloud & Infrastructuur

    Nieuwe Cisco-netwerkchip brengt quantum-internet dichterbij

    AchtergrondCarrière

    Ict-overnamemarkt trapt 2025 goed af, maar onzekerheid troef

    OpinieCloud & Infrastructuur

    Voorbereiding & verhuizing: zo implementeer je de hybride cloud

    ActueelCloud & Infrastructuur

    Europese Rekenkamer kraakt EU-strategie voor chipsector

    ActueelData & AI

    EU investeert bijna 2 miljard in digitale innovatie

    4 reacties op “Semantiek in versienummers”

    1. Pa Va Ke schreef:
      10 april 2019 om 13:34

      Er wordt één heel belangrijke limitatie vergeten als het gaat om versionering: wat kan/mag bij het betreffende product?

      Bijvoorbeeld een “-toelichting” zal in een aantal omgevingen niet werken omdat versionering beperkt is tot numerieke waarden
      Een jaartal als 2019 als eerste digit van je versie zal bij Microsoft MSI bestanden niet gaan werken omdat het eerste digit maximaal 255 mag zijn
      In embedded code gelden vaak weer andere conventies en limitaties.

      Kortom, er komt soms heel wat meer bij kijken dan hetgeen in het artikel geschetst wordt.

      Login om te reageren
    2. dino schreef:
      10 april 2019 om 16:57

      Eerste digit meer dan 9 ? Dat klinkt als fake versioning. Net als 6.0 omdat de concurrentie van een soortgelijk product bij 5.1 is blijven hangen. Of tsjaka nummering, officieel 7.5-stable, maar voelt als 7.6-alfa. GA, rolling releases, tagged repos. Alles getest in de pipeline, AB blauw groen. Vind ik leuk.

      Login om te reageren
    3. Kj schreef:
      13 april 2019 om 17:40

      Ik mis de commerciele component. Een tweede digit met 0 als versie nummer verkoopt immers niet.
      Een versienummer moet wel wat maturity uitstralen natuurlijk.

      Login om te reageren
    4. Pa Va Ke schreef:
      15 april 2019 om 16:36

      @KJ … ’t is maar hoe je het bekijkt. Ik heb ooit aan een product gewerkt waarvan de de .0 versie op het laatste moment terug moesten trekken en een .1 versie uitgebracht hebben.
      Reactie uit “het veld” : Hè, hebben we de 7.0 versie ergens gemist?

      Login om te reageren

    Geef een reactie Reactie annuleren

    Je moet ingelogd zijn op om een reactie te plaatsen.

    Populaire berichten

    Meer artikelen

    Footer

    Direct naar

    • Carrièretests
    • Kennisbank
    • Planning
    • Computable Awards
    • Magazine
    • Abonneren Magazine
    • Cybersec e-Magazine

    Producten

    • Adverteren en meer…
    • Jouw Producten en Bedrijfsprofiel
    • Whitepapers & Leads
    • Vacatures & Employer Branding
    • Persberichten

    Contact

    • Colofon
    • Computable en de AVG
    • Service & contact
    • Inschrijven nieuwsbrief
    • Inlog

    Social

    • Facebook
    • X
    • LinkedIn
    • YouTube
    • Instagram
    © 2025 Jaarbeurs
    • Disclaimer
    • Gebruikersvoorwaarden
    • Privacy statement
    Computable.nl is een product van Jaarbeurs