Standader eller riktlinjer för version nummer?

1.0.0.112 -> 1.0.0.162 = "Oops."
Patch. Ny build. Mindre buggfixar. Alltid gratis.

1.0.1 -> 1.0.2 = "Aha!"
Update. Omfattande buggfix. Kan innehålla uppdaterade contentfiler och vissa små featureförändringar, men i praktiken bara buggfixar. Gratis.

1.1 -> 1.2 = "Phew!"
Major Update / Upgrade. Rewrites, nytt content, ibland nya features. Bakåtkompabilitet är ett krav, och att ta betalt för en major update kan vara berättigat, men räknas som lite småsnålt. Apples operativsystem är väl den mest bespottade betalda uppdateringen.

1.0 -> 2.0 = "Tadaaah!"
Major Upgrade. Nya features, bakåtkompabilitet är inte ett krav men självklart alltid önskvärt. Här kan programmet helt byta interface eller få mängder av ny funktionalitet. Kostar nästan alltid pengar.

2.0 -> "SX" / "CS" / "MX" = "Please buy me?"
Ny plattform. Ditt program är nu så sönderbloatat och oigennkänneligt att marknadsavdelningen sliter sitt hår över hur man ska kunna locka befintliga kunder att ÄN en gång lätta på plånboken trots att programmet nu innehåller allt från mp3-spelare till webbläsare och två gigabyte tutorials.

I stället för att fixa de tusentals-och-åter-tusentals buggar som uppstått genom åren, byter man logotyp och frångår de vanliga sifferversionsnumren till förmån för en klatchig men totalt intetsägande tvåbokstavsförkortning, knökar in en mp3-spelare till och tar ut fullt pris. Sen kan karusellen börja om igen.

Ett vanligt system för Open Source är Major.Minor.Revision.

I princip samma sak som teetow sa fast istället för att särskilja på patch/update så slår man ihop de två stegen och låter det täckas av "revision".

En sak du måste tänka på är att inte falla i Open Source-fällan av att inte våga sätta 1.0 som version.

Det är alldeles för vanligt att man använder 0.99.112 av ett program för att utvecklaren/arna är rädda att 1.0.0 betyder att programmet är 100% färdigtestat och det ska sakna buggar helt, vilket ju inte stämmer.

När du släpper dina program, så se till att de har ett positivt heltal som Major-version.

Normalt sett brukar varje projekt definera sina egna riktlinjer. Man kan ju dock såklart ta inspiration från andra projekt ändå.

Var inte för rädd för 1.0, ett program behöver inte vara 100% buggfritt för att kallas 1.0, det är inte ett realistiskt mål i vilket fall. Se t.ex Wings 3D, som ligger på version 0.98.29b för tillfället eller burnatonce som ligger på version 0.99.5. Båda är användbara och stabila program som antagligen skulle ligga långt över version 1.0 om de inte vore så rädda för att kalla dem för det.

En enkel lösning är att helt enkelt använda revisionsnumret från sitt versionshanteringssystem, eh, VCS, Version Control System, typ CVS eller SVN.

Har man ett program som har någon form av API är en bra ide att dela in i ändrande versioner och bugfixande ellerförbättrande versioner. Python lägger t.ex. till nya funktioner i x.#-versioner och enbart mindre ändrigngar i x.y.#-versioner, på det viset vet man att ett program skrivet i en 2.4.x-version fungera i alla.

Hoppas det var till någon nytta.

EDIT: Meh, skriver(och kollar upp information) för långsamt.

En annan sak som kan vara värt att ha i åtanke:

Se upp med versioner som 0.9 och 0.10 och 0.10.x.x och 0.2.x.x. Ibland är 0.10 nyare än 0.9, fast vid sortering så kan 0.9 och 0.10 hamna lite olika (t ex WinXP som försöker sortera "smart").

Vad är det för snillen som sätter sånna konstiga versions nummer? Har dom ens gått i skolan? Vet dom inte om att 0.10 är det samma som 0.1 och därmed mindre än 0.9?

Det stämmer iofs inte, eller ja, det är en tolkningsfråga.

I Major.Minor.Revision-systemet så betyder 1.10.0:
Major version 1, första releasen av detta program.
Minor version 10 (tio), tio stycken uppdateringar har släppts/man har nått motsvarande nivå 10.

Medans 1.1.0 betyder:
Major version 1, första releasen av detta program.
Minor version 1 (ett), en uppdatering har släppts/man har nått motsvarande nivå 1.

Jag säger "man har nått motsvarande nivå X" då man i många fall hoppar över nummer om man gör väldigt många förändringar/buggfixar på samma gång, eller om man vill undvika problemen med x.10 och x.1 och hoppar över två nummer på samma gång (x.9 -> x.11, x.19 -> x.21). T.ex. Firefox uppvisar detta beteende då de hoppar från 1.0 direkt till 1.5, eftersom de känner att de har gjort så många förändringar i koden.

Personligen så tycker jag att den bästa lösningen är att hoppa över 10, 20, 30, 40 osv. och hoppa direkt till 11, 21, 31, 41 osv. Då har man konsekventa versionsnummer och man börjar inte fundera på tokiga saker som att öka Major när Minor når upp till 10.

Linuxkärnan:
2.4.22 / 2.6.6 == stable.
2.4.21 / 2.6.11 == unstable.

Jämna tal är stable och ojämna unstable.

Rätta mig om jag har fel

Vanligtvis ja, men det är inte alla som kör med det på revisionsnivå, utan många kör med det på Minor-nivå.

T.ex. 2.4.x == stabil release, 2.5.x == utvecklings/unstable.
Och så blir 2.5.x till 2.6.0 när den släpps som stable.

Varför krångla, skriv bara vilken build det är så som patcharna till t.ex UT2004 är skrivna.
http://www.fz.se/filarkiv/?s=&p=spel/ut2004/Patchar/old/

lite smått jobbigt å veta hur stor uppdatering det är bara..

Jag avgudar dig nu.

På wikipedia kan man läsa lite om versioner:
http://en.wikipedia.org/wiki/Version
En lustig sak är att Tex sen version 3 lägger till 1 siffra ur pi per version, så den senaste har versionsnummer 3.141592