Versionsnummerering

Jeg har tænkt på to forskellige, men nu slået dem sammen:

(Jeg har surfet lidt og fået lidt information)

For ikke at have alt for mange tal man kan klokke rundt i kunne man håndtere det på den måde at man har:
 - (major version) . (stable/unstable) . (bug comment)
Forklaring:
 - eksempel1: 1.3.A
 - eksempel2: 4.6.R

Hvis man tager eksempel1 _majorVersion_ vil blive bestemt ved at der bliver tilføjet STORE forandringer/tilføjelser.
 dvs. majorValue == 0 -> brand new project
       majorValue == 5 -> some feature has been added since the begining

Men hensyn til _stable/unstable_ kunne man gøre dette ved lige og ulige numre:
 dvs. stable/unstable == 3 -> unstable
       stable/unstable == 6 -> stable

Bug comment er lidt for sjov, men kunne være en god idé hvis man ikke føler de to andre er helt nok:
   bugComment = S -> "Starting, be careful"
                          A -> "Acceptable number of bugs"
                          F -> "Fewer bugs"
                         R -> "Really god version, was Linus here?"

Så kunne man jo sige at den går i et hierarki. Nemmest at tage den bagfra:
- Lad os sige at _stable/unstable_ går fra 1 - 10, så alt efter hvordan vi føler projectet/programmet kører, kan man dele 1-10 over de 4 bogstaver som følgende:
 1 -> S
2-3-4 -> A
5-6-7 -> F
8-9-10 -> R

Men dette kan self. variere. Man kan droppe S eller lign. der behøver ikke være lige mange i hver "gruppe".
Så på den måde siger bugComment hvordan stable/unstables bug-tilstand er.
ELLER så siger bugComment hvordan majorVersion's bug-tilstand er.

Det leder samtidigt over til, at når bugComment når til R så burde den være STABLE hvilket kan gå hurtigt eller langsomt, dvs at stable/unstable behøver/skal ikke op og ramme 10.
Så når bugComment rammer R så er det tid til majorVersion skrift!

Jeg har ingen anelse om du forstår det? Vil meget gerne tegne det.. GRRR..
Og jeg bruger mange engelske ord fordi det var lige det der faldte mig ind, ellers lød det bage forkert at sige/skrive på dansk.

Ellers må vi lige en tur på irc... så jeg kan forklare det med små sætninger og så du kan still spørgsmål. Men hvis du forstår så er det godt klaret af mig.

Finale svaret, ville være en oplagt mulighed at smide noget op på vores FAQ

Lyder godt.

jeg foreslår at det har dette format. #.00.00, så major løber fra 0 og opad, imens minor løber fra 00 til 99 og bugfix løber fra 00 til 99 også.

Stable/unstable lyder som en fed ide, men jeg er lidt i tvivl om hvad det er. Kan du mon forklare lidt om hvordan man definerer stable og unstable?

Jeg syntes det er en fed idé med 00-99 i forhold til bugfix. Det vil så vil foreslå vil være hvis vi lavede en grov skala over de 00-99, som betegner mængden af bugs lidt ligesom fra 00-22 har ditten beskrivelse og 23-?? har datten beskrivelse. så vi har et fast greb på hvad de forskellige tal betyder og de har en fast værdi i stedet for at det næsten bare er et tal der stiger og starter forfra i næste version ;)

Det kunne også være fedt hvis tallene har en afhængighed af hinanden, det var det jeg godt kunne lide med min:
når stable/unstable tallene steg fulgte bogstaverne med og når bugstaverne når til R så er det tid til major skrift.

I forhold til stable/unstable er et godt eksempel på ustabilitet ville være vores/dit BPM program. Det var utroligt ustabilt og kunne svinge MEGET og man kunne få en BPM på 90 selvom sangen faktisk havde 130bpm .

Så hvad jeg fortolker det som:
STABLE: Programmet er 99% non-crashable. Har et stabilt output der ikke varierer, dvs. fejlprocenten er lav.
UNSTABLE: Programmet kan crashe ved valgt af en forkert menu, eller hvis man trykker på en bestemt knap der ikke er navngivet/fortalt til brugeren at denne lukker programmet. Hvis fejlprocenten er høj, som forklaret med 90bpm/120bpm eksemplet.

Man vurderer sammen eller selv hvordan fejlprocenten ligger, ved at teste. Efter min mening kan man vurdere det allerede i den testing man laver imens man programmerer. Jeg ved ikke om dette er nok forklaring men ellers prøv at kigger her:
http://en.wikipedia.org/wiki/Instability

I forhold til stable/unstable har jeg sikkert glemt det, men der er mange frie fortolkninger af den, da folk tilpasser det til deres program, det samme kan vi gøre. Tænk lidt at vi har en STOR farlig dinosaur i et bur, hvis buret KUNNE knække eller mangler nogle tremmer er BURET ustablit. Dog hvis buret er stærkt og måske har strøm i, så løber den ingen steder og buret er stabilt.
Samme historie kan man bruge i forhold til vulkaner, but you get the drift?

Ja det kan jeg godt se.

Så synes jeg vi skal prøve med bogstaverne til bugfixes.

Men skal der så kun være major og bugfix?

Eller skal der være major, minor og bugfix?

Anders fortalte mig et skide godt bud som ligner vores MEGET indtil videre. Vil lige høre ham her i aften om han ikke lige vil forklare det en gang mere, den var også meget enkel.

Så har jeg fået snakket med ham:

Anders' versionsnummerering:
Major.Minor -> #.#(#)

Man starter ved f.eks 0.1 som er starten (kan også starte ved 0.0, men det er lidt underligt)
For hver "milestone"/implementering øges Minor med 1 og der smarte er så, at han også har stable/unstable med i denne versionsnummerering:
Hvis versionen har bugs eller er ustabil så tilføjes det det andet Minor tal eks 0.11

Det jeg syntes er smart ved denne er at man slipper for at tænke over lige/ulige tal og det hele bliver lidt mere smeltet sammen og man meget hurtigt kan se hvordan processen går. Jeg ved ikke om jeg har forklaret det nok, men en ting man så kan tilføje er bogstaverne i min forrige post. på den måde ved man hvor man er i forhold til Major. Minor kan man se hvor langt selve programmet er, og om den er stabil/ustabil og samtidigt se hvordan processen er med Minor med bogstaverne.

Jeg ved ikke hvad du syntes om dette? Syntes heller ikke vi skal bruge ALT for meget tid på at finde versionsnummereringen, da jeg er bange for at dette kan sænke os ned i et sort hul meget nemt.

Jeg syntes det skulle være Major.Minor.Bugfix .

Anders har fat i noget.
Jeg vil nu foreslå at vi laver den sådan her:
#.#(.#)
Så hvis vi har en minor version klar, hedder den fx. 0.1
På vej hen til nummer 0.2, starter vi med et par bugs, og hedder derfor i rækkefølge:

0.2.s (starting)
0.2.a (acceptable)
0.2.f (few)
0.2.r (really good)
0.2 <- stable

Det er sådan vi gør det! En god solid plan.
Jeg vil prøve og se om jeg kan lukke tråden (så har jeg prøvet det ;) ) og markerer den som Solved.

Tråden er løst. Den kan dog altid åbnes igen, hvis denne løsning ikke fungerer optimalt.

Der er nu tilføjet en FAQ til denne tråd.
FAQ #1569: “Versionsnummerering”.