Efter ni kommer ti...

Af 29

Er alle med indtil videre ?

Godt, så kommer trickspørgsmålet:

Hvor mange ciffre er der i ni, henholdsvis ti ?

Glimrende.

Er der så nogen der kan sige hvorfor flg. er en dum ide:

v=`uname -r`  
m=`expr "$v" : '\([0-9]\).*'`  
if [ $m -lt 5 ] ; then  
    echo  "Too old FreeBSD version" 1>&2  
    exit 1  
fi

Lige nu er ports totalt bombet fordi autocrap værktøjerne og en del anden software slet ikke kan forestille sig operativsystemer med to cifferede major-versioner.

Apollo's Domain/OS havde samme problem, der kom et utal af obskure 9.mumle varianter inden de endelig tog sig sammen til at kaste version 10 på gaden.

Og burde vi egentlig ikke have lært den lektie for 11 år siden ?

phk

Kommentarer (29)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
#1 David Rechnagel Udsen

Bør man ikke bruge [0-9]+ når man søger efter numre i strenge?

Jeg husker at Opera 10 måtte bruge Opera 9 i sin user agent p.g.a. nogle servere troede ALLE versioner kun havde ét ciffer. Chrome sagde 'fuck det, folk kan bare opdatere deres lort'. Og det kan de. Og det bør de.

Det er ikke så svært at addere et plus til ens regex.

  • 9
  • 0
#8 Peter Makholm Blogger

Egentlig burde det være overkommeligt at skrive en fungerende rutine til at sammenligne versionsnumre for et enkelt konkret produkt.

Det er først når man prøver at bruge det samme reglsæt på alle de mulige og umulige måder folk vælger at giver deres software versioner på. Jeg har set projekter der i fuldt alvor brugte en følge af versionsnumre der hed 1.0 -> 1.1 -> 1.11 ->1.12 -> 1.2 -> 1.21 -> 1.3 hvor versionsnumrene med to cifre efter punktummet var bugfixes. Hvordan de ville håndtere de to større ændringer efter 1.9 ved jeg ikke, men måske ville det være en automatisk grund til at skifte til 2.0. Så er der folk der bruger 1.3a -> 1.3b -> 1.3c om bug fixes, mens andre bruger 1.3mumle1 om forskellige former for prereleases af 1.3. Nogle tillægger _ og ~ specielle betydniger.

Næste større projekt tror jeg bare jeg tagger hver version med et uuid. Så må folk tage sig til takke med at undersøge om de har en specifik version af min kode eller ej...

  • 4
  • 0
#12 Deleted User

Vores ord for tal - f.eks. "ni", "ti", osv. - repræsentere værdier, ikke tegn. I nogle ordbøger kan findes: "elleve [..] også i formen 11.". Altså kan A i base 11, eller 16 for den sags skyld, godt udtales "ti" (som pga. vores standarder også kan skrives 10, men det ville bare forvirre endnu mere :).

Det ikke sagt at man nogle gange støder på specielle ord, for værdier i andre baser end 10, men jeg tvivler på det er officielle? Kunne være meget sjovt hvis nogen kunde finde dokumentation.

  • 0
  • 2
#14 Casper Bang

Egentlig burde det være overkommeligt at skrive en fungerende rutine til at sammenligne versionsnumre for et enkelt konkret produkt.

Men jeg vil jo påstå du har dit problem lige dér! Hold dog op med at skrive de samme buggy rutiner igen og igen, og træd istedet et skridt op i abstraktionsniveau.

Med andre ord, brug nogle ordentlige konventioner og værktøjer! I Java verdenen har vi Maven til at skrive projekt objekt modeller, der gør styring af dependencies og versionering af artifakter til en leg.

  • 1
  • 2
#15 Torben Mogensen Blogger

TeX bruger versionnumre, som er approksimationer af pi: 3, 3.1, 3.14, 3.145, osv. Her er man i hvert fald sikker på, at der kun er et ciffer før decimalpunktummet.

Jeg foretrækker selv at bruge release-dato som versionsnummer.

  • 1
  • 0
#16 Filip Larsen

På Android fastlægges versionen af både platformen, applikationer og databaser med et monotont voksende heltal så her er det ingen sag at afgøre, om én version er nyere end en anden - såfremt man altså kan finde ud af at indlæse alle cifrene i dette heltal :). Til disse versionstal hører også et versionsnavn til, som fx "1.2.3" der kan præsenteres til brugeren hvis det ønskes, men som ingen betydning har i forbindelse med at afgøre hvilken versioner der er nyere.

  • 2
  • 0
#17 Søren Chrestensen

Det var en hel anden situation. Linux skiftede jo "helt" versionsnummer layout, som gjorde at en masse tools ikke ville virke. Havde Linus valgt at skifte til 2.8.x.y eller 3.0.x.y havde der jo ikke rigtigt været nogle problemer. Men nu valgte han jo at skifte til 3.x.y hvilket også er det rigtige at gøre, men der må man forvente at nogle værktøjer ikke virker efter skiftet, da de ikke har taget højde for at layouttet ændrer sig lidt.

  • 0
  • 0
#24 Torben Mogensen Blogger

Bruger du så ISO format eller noget andet som er svært at parse?

Normalt står versionsnummeret kun i kildeteksten og dokumentationen, så jeg har ikke bekymret mig om at gøre den maskinlæsbar. Men datoen er en god indikation for, om den version man sidder med, er gammel eller ny. Hvis der var behov for et maskinlæsbart format ville jeg nok vælge YYYYMMDD for at gøre datoen læsbar og sorterbar som heltal.

  • 0
  • 0
#26 Erik Cederstrand

Jeg foretrækker selv at bruge release-dato som versionsnummer.

Det er jo TOTALT UPRÆCIST!!! Hvordan kan du bare angive en dato, uden at fortælle om det er i den gregorianske, julianske, islamiske, kinesiske eller jødiske kalender, formatet for datoen og tidszonen for udgivelsen? Og hvad nu hvis du har flere commits på én dag? Så kan du ALDRIG finde tilbage til den oprindelige kode. Makværk, siger jeg.

:-)

  • 3
  • 1
#29 Casper Bang

Er der rent faktisk nogen der nyder at bruge Maven?

Maven kan være besværlig (hvorfor er release:prepare og release:perform ikke én atomar handling?), men når det så er sagt, så kan man tage en masse problemer up-front, som man ellers ville være i dårlig stand til at udrede senere hen.

Så jeg vil sige at mens Maven måske ikke er perfekt implementeret, så er det godt nok smart når man kan finde ud af at bruge det, og konventioner slår altså imperative scripts (make, ant, you-name-it).

  • 1
  • 0
Log ind eller Opret konto for at kommentere
Job fra Jobfinder
Tip redaktionen