Minder standaardisatie in het versie nummer
Standaardisatie in software versie nummers is er wel, maar wordt niet echt consistent toegepast.
De eindgebruiker wil niet weten welke versie nummer van software er gebruikt als het maar de laatste versie is.
Omdat eindgebruikers niet veel getallen wil onthouden en het niet makkelijk vinden om mee te werken gebruiken sommige software uitgevers daarom maar een naam voor iedere release. Maar er is nu ook een nieuwe trend om vaker het major nummer van het versie nummer te verhogen. Het goede is dus dat met het vaker verhogen van het major nummer makkelijk is voor eindgebruiker verandering bij te houden.
Maar het zorgt ook voor verwarring met software uitgevers die het traditionele manier van versie nummers gebruiken.
Maar wat is het traditionele manier een versie nummers geven eigenlijk? Ik zelf handteer een aantal vuistregels om te bepalen welke nieuw versie nummer een software release moet krijgen.
– Een versie nummer bestaat uit de volgende 4 getallen: major-, minor-, release-, build nummer.
Verder kan een woord toegevoegd worden dat de kwaliteit aangeeft, dit kan zijn: alpha, beta, rc. Wanneer het niet gebruikt wordt is het een stabiele final versie. Het build nummer mag voor de eindgebruiker weggelaten worden, omdat dit getal niks nuttig voor de eindgebruiker vertelt.
– Voor een nieuwe major nummer moet minstens 50% van de broncode ten opzichten van de vorige major release verandert zijn.
– Voor het verhogen van het minor nummer moet minstens 10% van de broncode ten opzichten van de vorige minor release verandert zijn. En er moet ten minstens 1 feature toegevoegd zijn.
– Voor een nieuwe release versie moet er ten minstens 1 bug opgelost.
– Een build nummer wordt verhoog iedere keer dat broncode gecompileerd wordt.
Welke vuistregels voor het toepast worden de niet traditionele snellere major releases, lijkt te zijn dat wat minor releases gedaan wordt nu als major release gepresenteerd wordt. Consistent en gestandaardiseerd is het nog niet.
D9ping