D9ping

Ik heb eindelijk de final versie van 2.0.0 uitgegeven.
De verandering sinds versie 1.0.4 zijn merkbaar. Er is zeker meer dan 80% van de code van in de tweede major release verandert t.o.v. eerste major release. Zoals al eerder meegedeeld is versturen van een notitie naar twitter® of facebook® verwijdert. Dit omdat de gebruikten REST protocol dit mogelijk te maken niet meer ondersteunt wordt. Nieuw in versie 2.0.0 is dat skins, nu volledig uit bestand geladen worden. Dit maakt het mogelijk voor de gebruiker mogenlijk zelf nieuwe skins toevoegen aan NoteFly. Over het algemeen is de broncode is veel beter uitbreidbaar geworden. En na de release candicates1 is de syntaxhighlighter voor html, php en sql weer opnieuwe geschreven. De syntaxhighter moet nu veel meer correcter werken dan voorgaande versie’s. De syntax highlighter is nu ook veel gemakkelijker uit te breiden met een nieuwe taal om syntax highlighting op toe te passen. Dit komt doordat de manier hoe de taal eruitziet extern in langs.xml bestand vastgelegd wordt in plaats van in de broncode hardcoded. Verder zijn in de nieuwe major versie veel instellingen toegevoegd zodat het programma op meer fronten aan pasbaar is.
Over het algemeen is NoteFly 2.0 t.o.v. een grote upgrade onder de moterkap hoe het programma werkt maar bevat daarnaast toch nog een flink aantal features en verbetering die niet direct zichtbaar zijn.
Verder heb ik de website van NoteFly nog een nieuw design gegeven.

update: NoteFly 3.0.0 uitgegeven

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.