minecraft 1.0, 1.2 1.2.1 osv

["datanerden"]

Hva beyr de forskjellige tallene, hvordan vet man hva man skal forhøye, er det noen spessielle regler for det. i mange programmer og spill ser jeg sånne tall, men skjønner ikke helt hvordan det virker.

Og hva skjer når man går over 10 noen plasser?

Endret 8. februar 2015 av "datanerden"

[Zash]

Det er hvilken versjon det er.

Kort fortalt så økes første nummeret når det er en stor endring, andre nummeret ved en liten endring, og tredje nummeret ved en liten fiks.

For tallene du nevnte: 1.0 er første utgivelse. 1.2 er etter en liten endring. 1.2.1 er etter en liten fiks.

["datanerden"]

Tusen takk, men hva skjer når man kommer til over 10

[Zash]

Etter 10 kommer 11... 11.1.2 for eksempel. Eller 2.11.4.

[Gjest Slettet-aNZFa3]

For alpha og beta så er det vanlig å legge til -alpha1 / -a1, -alpha / -a, -beta1 / -b1, -beta / -b for en tidlig versjon. For versjoner som er nesten klar (release candiate) så er det vanlig å legge til -rc1 (første release candidate test).

 

Så for alpha test av versjon 1.2, så blir det f.eks: v1.2-alpha1. For beta test av versjon 1.2 så blir det f.eks v1.2-beta1. Når versjon 1.2 er nesten klar (release candidate) så blir det f.eks v1.2-rc1. Og når 1.2 er klar for utgivelse så blir det bare v1.2.

Hvis man finner noen feil etter at versjon 1.2 er gitt ut så er det vanlig å legge til f.eks x.x.1, så da blir versjonen v1.2.1. Hvis man finner da en liten feil med 1.2.1, så blir det ofte lagd en "hotfix" for den versjonen. For enkel lesbarhet så blir den skrevet som v1.2.1 Hotfix 1, i selveste programmet (enten i den bygde kjørbare filen, eller bare i prosjektet (assembly versjon)) så blir "Hotfix 1" skrevet som v.1.2.1.1, som oftest vises kun internt, så det blir enkelt å administrere de forskjellige endringene i kildekoden. Man bruker ofte et versjonskontrollsystem for å holde orden på dette. Med et sånt system så kan man enkelt "gå tilbake" til en tidligere versjon i utviklingen (eller utvikle 2 versjon parallelt og sette de sammen etter ("merge")), hvis det er noen endringer i den nye versjonen som gjorde at noe ble ødelagt.

 

Det er også vanlig å sette "build number" bak versjonnummeret, f.eks, v1.2.1 4076 / v1.2.1 BUILD 4076 / v1.2.1.4076, hvor 4076 er "build number". Implementeringen av "build number" varierer, men den blir ofte inkrementert med +1 etter hver intern test eller etter at programmet har blitt bygd til en kjørbar fil. Noen bruker også en implementasjon av dato som "build number".

 

Du kan lese mer her:

 

• Versjon navngivning: https://en.wikipedia.org/wiki/Software_versioning
• Versjon navngivning: http://semver.org/
• Versjon navngivning og "build number": http://programmers.stackexchange.com/questions/24987/what-exactly-is-the-build-number-in-major-minor-buildnumber-revision
• Kilde / verrsjonkontroll: http://betterexplained.com/articles/a-visual-guide-to-version-control/

Endret 10. juni 2016 av Slettet-aNZFa3