Als software engineer is het allemaal niet zo onlogisch. Ze hebben overduidelijk 4-weekse Agile sprints, vandaar dat in beginsel alleen veelvouden van 4 in de weeknummers verschijnen. Dat diskwalificeert echter niet dat ze:
- In de tussentijd een keer een branch trekken voor een speciaal geval. Dan krijg je bijv. 2019.15.x ineens ertussendoor
- Dat ze binnen een sprint features gaan mergen. Dan gaat groep 1 aan de gang met 2019.32.1 bugs fixen uit 2019.32, welke uit 2019.28 is ontstaan, en groep 2 gaat features uit 'master' of experimentele branches terugmergen in 2019.32.2. Je kan dan zelfs krijgen dat er een aparte bugfix branch 2019.32.3 sequentieel wordt getrokken die dus featurewise dan achterloopt op 2019.32.2 maar gewoon later is gesplitst
Vanuit Tesla's cases met dat ze diverse softwarevarianten tegelijk moeten onderhouden (pre-alpha, alpha, beta, limited EAP, wide EAP, advanced general public, standard general public) is het allemaal niet zo verbazend. Gewoon niet ervan uit gaan dat er tijdens 1 sprint meerdere features releases komen (dat is zelfmoord) en voor de rest geen sequentiele betekenis leggen op de branches.
Dus long story short: Tesla's version strategy is <year>.<week of branching>.<branch number>.<patch level within branch>. En voor buitenstaanders is branch number het minstzeggende getalletje daarin.
