Het maakt niet echt uit of het een bibliotheek of een grotere applicatie is. Een semantisch versiebeheerschema werkt perfect voor grote applicaties. Het kan zelfs worden gebruikt voor een verzameling applicaties die zijn gebundeld tot een platform, maar hier wordt het behoorlijk moeilijk om aan te pakken.
De belangrijkste vraag is of je de route van ondersteunde afschaffing in één release gaat volgen en deze pas in de volgende hoofdversie verwijdert. Het hebben van afgeschafte, maar ondersteunde functionaliteit, kan behoorlijk wat inspanning vergen. Wanneer je wijzigingen gaat aanbrengen in je opgeslagen gegevensmodel, kan afschaffing vaak onmogelijk worden. Als dat gebeurt, kun je niet eens een kleine versie met afgeschafte functionaliteit doen, en spring je direct naar een volgende hoofdversie. Dit is het deel waar grote applicaties meestal problemen mee hebben. Je gaat van 3.0.0 naar 3.0.1 naar 4.0.0 omdat je geen achterwaartse compatibiliteit kunt bieden. Als je vaak compatibiliteitsproblemen hebt, voegt het vasthouden aan semver weinig waarde toe.
Dat gezegd hebbende. Ik geef veel meer de voorkeur aan die constructie omdat het duidelijker communiceert naar ontwikkelaars dat er compatibiliteitsproblemen zullen zijn. Het YYYY.N-schema zegt mij niets als ontwikkelaar, en niets als beheerder.
Dus de vraag is, wat wil je communiceren met de versie? Als je 6 feature-releases wilt doen (die wel of geen compatibiliteitsproblemen kunnen hebben), en elke 6e release langer wordt ondersteund met patches; en je wilt patch-releases niet versie-nummeren. Dan is X.Y een geschikt schema waarbij Y=0 de langer ondersteunde is. X zou gewoon een nummer zijn. Het probleem is wanneer X het jaar is, dan wordt Y snel geassocieerd met een maand. Dus nieuwere, langer ondersteunde releases worden in januari uitgebracht? Ik moet altijd opzoeken welke Ubuntu-versie een LTS is, wat me irriteert.
Dus wat als Discourse gewoon doorgaat met de huidige hoofdversie. De volgende langer ondersteunde versie heet 4.0; en dan krijgen we 4.1 tot 4.5 als feature-releases; gevolgd door 5.0 die de nieuwste langer ondersteunde is.
Dan heb je ook niet dat ongemakkelijke moment waarop een release wordt uitgesteld vanwege een groot probleem.
Je kunt optioneel een “patch”-nummer toevoegen als je van plan bent expliciet patches uit te brengen (in plaats van doorlopende patch-releases). “Maar dan heb je x.y.z wat semver is”. Nou nee, het lijkt op semver, maar dat is het niet. Elke nieuwe “minor” release kan compatibiliteitsproblemen hebben. Dus ik stel voor om gewoon vast te houden aan het X.Y-versieschema met Y=0 → LTS.
Versietaal terzijde. Ik hou van het nieuwe releaseplan.