Závod v číslování verzí programů

6.12.2010 08:49 | Přečteno: 2252× | gnu_linux | poslední úprava: 6.12.2010 08:49

Připadá mi, že se někteří vývojáři pomátli. Google chce s Chromem evidentně předehnat IE v číslování, což se mu za pár měsíců povede (aktuální vývojové verze jsou Chrome 9 a IE 9), dnes jsem narazil na další pěkný příklad, který mě aspoň po ránu trochu pobavil. Jedná se o známý komprimační program 7-zip. Ve Woknech v práci jsem si po roce řekl, že se zkusím podívat po aktuálnější verzi a zní to až neuvěřitelně, ale opravdu se to stalo (viz výpis dole).

 
7-Zip 4.65  Copyright (c) 1999-2009 Igor Pavlov  2009-02-03

...

7-Zip 9.20  Copyright (c) 1999-2010 Igor Pavlov  2010-11-18

       

Komentáře

[AlastorM]

jo, to je dobrej skok :D - ze 4.65 na 9.xx. Přitom počet oprav z oficiálního webu by odpovídal skoku tak na verzi 5.xx nebo 6.xx - ale podrobně jsem to nezkoumal. Možná je ale číslo 9 v módě

[kip]

Kdepak módní devítka. Podle FAQ je to s verzováním takhle:

7-Zip 9.20 - it's revision 20 of 7-Zip 9 (started in 2009)
7-Zip 4.65 - it's revision 65 of 7-Zip 4 (started in 2004)

[Amarok]

Tim autor podle me stejne neobhaji ten velky skok. Stara vetev (4.xx) uz se na homepage neda stahnout, je tam jenom 9.xx. Stara verze je jen na sourceforge. V tom FAQ to ale dela dojem, jako by se na obou vetvich pracovalo dal paralelne, coz ale neni pravda (posledni verze 4.xx je z 2009-02-03). Cili porad nechapu, proc 9.xx nema cislovani od 5.xx. Kdyby to bylo podle roku, tak by autor verzi 4.58 ze zacatku roku 2008 uz ocisloval jako 8.xx.

[AHAHA]

Autor hlavne nema zadnou povinnost sve cislovani verzi sveho programu nijak obhajovat.

[kralyk z abclinuxu]

+1

[Amarok]

To je zase diskuze... Tady nejsme v soudni sini.

[fred]

ok, potom zdarma napis lepsi komprimacni program a kazdy milenium zvedni verzi o 0.0000000000001 třeba.

[Amarok]

Bezva. Tady nekdo nepochopil, jak jsem to cele myslel.

[fred]

co jako, proste si myslis, ze cislovani nekterych programu proste neni vhodne. to je pekny, ale kdybych ja mel sepsat to co mi vadi a myslim, ze by to slo udelat 100x lip tak je to na celou knihovnu :/ lepsi neresit.

[Amarok]

No jasne, jenze ja o tom proste napsal zapis do blogu :) Proc ne. Tady se jinak resi casto voloviny... tak aspon je o cem diskutovat.

[mimi.vx]

+1, a proste zvolil cislovani zalozene na roku kdy zacal praci na te verzi

[Marián Kyral]

A příští rok se můžeme dočkat verze 1.10

[AHAHA]

Ach jo.

Google zvolil svuj aktualni vyvojovy model prave kvuli tomu, aby ciselne predehnal IE. Za par let tu bude Chrome 50 a IE bude jen 11 a vsem bude naprosto jasne, ze Chrome musi byt 50/11 krat lepsi nez IE, protoze to rika verze.

To fakt pripada jen mne tak absurdni srovnavat verze napric projekty? Vzdyt je uplne jedno, jestli je to 1.253 a nebo 253!

Google to dela spravne. Proc by mel cislovat 1.6.7, jen aby uspokojil "srovnavace", kdyz jeho vyvojovemu modelu daleko sedi jednoduche inkrementalni celociselne verzovani?

[Jendа]

253! je bohužel dost nepraktické číslo. Nejsem si jistý, jestli jsou současné balíčkovací systémy připravené na vyhodnocování výrazů a uvádění vypočítaného čísla v názvu balíčku je se současnými souborovými systémy nemožné

touch: nelze se dotknout (provést příkaz „touch“) „51734609926400789218043308997295274695423561272066399607484636163134302903130041238314437828111213744932542876617296316904840977852744354743364096544589631199800576352102197345093407901685444661637384445171444589249826159309289810622514481898739824349965672944938199095203108731528570965561754517676626034976542767771987626709597099937322577683908278497279328468806763572731103332796695726049211496386749680456221513530752014396144012492800000000000000000000000000000000000000000000000000000000000000“: Příliš dlouhé jméno souboru

[SPM]

No ještě by to šlo zaokrouhlit a použít zápis AeX (A*10^x), to by balíčkovací systémy asi sežraly, nicméně se obávám, že většina z nich by považovala 3e50 za novější verzi, než 2e150 :))

[AHAHA]

No proto jsem jej zapsal jako 253! Dalsi verze by byla 254! a "srovnavaci verzi" by se mohli po**at vzteky.

[Mortal]

asi marketingovy trik pro BFU, kteri si mysli, cim vyssi cislo tim lepsi
u slackware se kdysy taky preskocilo nekolik cisel
zase jsou opacne extremy, programy ktere jsou mnoho let stabilni a jeste nedosli k verzi 1 :)

[Amarok]

Presne takhle to taky vidim, je to kvuli BFU a mezi prohlizeci je konkurencni boj aktualne asi nejvetsi.

Ty opacne extremy jsou hlavne u open source a to mi i docela vadi. Lidi na to proste koukaji skepticky, kdyz jim navrhuji neco, co znam z Linuxu, a je to uz par let ve verzi < 1. Woknari pak pronesou neco jako "chacha, vzdy to jeste nejaka beta verze, tak to radsi neee, podivam se po necem jinem" a stahnou si pak nejaky freeware/shareware, ktery toho ani tolik neumi. Tezko s nima o tom diskutovat.

[mimi.vx]

u slackware to bylo dano delsi pauzou a prechodem z libc5 na glibc ...

[IT expert]

Sve programy cisluji od 1 do x. Nevidim duvod, proc bych to mel drobit na mensi...

[sivlk]

Ja rovno pouzivam SVN revizie, tak aspon je jasne co to cislo znamena, da sa dohladat datum, changelog, atd.

[Trained.Monkey]

Ja pouzivam SHA hash z GITu

Asterope.03712d973bccc38baf67ea6f7aea2178eaa8cd65

[Marián Kyral]

To je opravdu lehce zapamatovatelné. A navíc nepoznáš, jestli máš starou nebo novou verzi.

[Josef Kufner]

Ono celočíselné verzování je takové hrubé a nelze odlišit malou opravu od větší změny. Na většinu programů je optimální používat dvoučíselné verzování (x.y). Při opravách a malých vylepšování se zvyšuje y, při větších změnách x. Při troše opatrnosti pak uživatel může být v klidu, že pokud se jen změní y, tak se mu nic nerozbije a při změně x by si to radši měl zkontrolovat (hlavně pokud to má propojené s něčím dalším).

Výborné je git-describe, které produkuje řetězce ve tvaru Tag-N-gHash, kde N je počet commitů od poslední verze a Hash je identifikátor aktuálního commitu. Takže pokud jsou v projektu tagy ve tvaru v1.2, tak pak generované označení vypadá třeba takto: "v1.2-15-g4af2d8" (= 15 commitů od verze 1.2). Samozřejmě, pokud se aktuální commit shoduje s tagem, tak tam je jen "v1.2". V případě spolupráce více lidí se ještě hodí na konec připojit iniciály autora, aby bylo jasné od koho je ten či onen balíček ubalen (v případě, že to opustí repositář).

[Ivanhoej]

najlepsie cislovanie je napr. 20100812 a pod proste datum vydania je to prehladne a jednoduche.

[frEon]

co kdyz v jeden den vyjdou 2 verze? rano vydam verzi, nekdo nahlasi krit chybu, jeste ten den vydam opravu. mam cekat do dalsiho dne?

[Marián Kyral]

co kdyz v jeden den vyjdou 2 verze? rano vydam verzi, nekdo nahlasi krit chybu, jeste ten den vydam opravu. mam cekat do dalsiho dne?

Ale no tak, je tady několik logických možností: 20100812-1 nebo 20100812.1 případně 20100812-15:28

[frEon]

ne me vsechny prijdou strasne nesystemove. az na ty minuty, ale tam mi prave prijde, ze uz tech cisel je tolik, ze se to bez kalkulatoru spatne porovnava...

[Tomáš]

Když vydáš verzi, která má ještě týž den nahlášenou (kritickou!!!) chybu, tak by sis měl v prvé řadě sednout, a zamyslet se. Oprava tak zcela přirozeně může vyjít až další den.

Já osobně přidávám do identifikace binárky unix time (s přesností na sekundu), páč nevím, co mi vyrvou z pod rukou, tak abych věděl, z jakých zdrojáků to vlastně bylo.

[miso]

Ta kriticka chyba nemusela byt sposobena poslednou upravou. Aky je vlastne dovod "může vyjít až další den"?

[Josef Kufner]

No vidišto. A já když v aptitude vidím nějaký balíček takto očíslovaný, tak z toho poznám prd. Kdežto klasické číslování (x.y) mi aspoň napoví, jestli mám upgrade dělat před nabo až po dodělání domácího úkolu.

[tmr]

Vzhledem k tomu, že se Chrome updatuje automaticky, je úplně jedno jestli se hlavní číslo mění každý týden nebo každý rok. Nevidím důvod, proč by měli číslování zpomalit.

[gtz]

jenže funkčnost také někdy je důležitá, Chrome ano to funguje, ale googleeath ve verzi 5.X je naprosto nepoužitelný - padá a někdy se ani nerozjede.

[mimi.vx]

proto je google earth 6.0 :)

 

jinak u chrome je cislovani x.0.vyz ... pricemz sou dulezita tri posledni cisla .....

[Amarok]

Chrome se updatuje automaticky? Ve Woknech ano, ale u me v Linuxu urcite ne (mam teda Chromium a ne Chrome, ale v tom nebude rozdil).

Jak uz se tady psalo, je dost dobre, kdyz podle cislovani mohu posoudit, zda nemam pred updatem napr. pro jistotu zazalohovat nektere soubory. Napada me ted napr. PostgreSQL, kde se doporucuje pred kazdym vetsim skokem ve verzi zaloha databaze, jelikoz vetsi skok muze znamenat, ze se zmenil zpusob pristupu k databazi a mohlo by to existujici DB rozhodit.

[gtz]

Ano, přes Yast/zypper/updater applet. Chrome po instalaci si doplní svoje repositáře a doplní do cronu i script na toto.

Teď jsem si hrál s earthem a je nová verze 6.0 beta, která nějak funguje.

[Amarok]

Tak to jsem fakt rad, ze Chromium takove silenosti v Archu nedela. Nemam rad, kdyz si aplikace delaji na pozadi vlastni veci, o kterych nevim. Kdyz chci update, tak ho spustim sam (samozrejme ale spoustim update vsech balicku najednou).

[Josef Kufner]

Tohle dělá Google Chrome, ne Chromium.

[Amarok]

Aha, to pak vysvetluje situaci. Ja jsem to napsal prave spatne, od zacatku pouzivam Chromium a neznal jsem, ze je tam tenhle rozdil. A to teda dela Chrome ve vsech distribucich?

[mimi.vx]

ano , vsude tam kde to chrome podporuje ... -> toto je jeden z hlavnich rozdilu oproti chromiu

 

google predpoklada ze chromium pouzivaji lide kteri vedi jak si aktualizovat sytem , applikace atd

zatimco chrome je jejich offic baleni urcene i pro naproste BFU ....

[tmr]

No v Linuxu to je podobny, tam by se mel o updaty starat balickovaci system. Alespon v Chrome / Ubuntu to tak je. V PostgreSQL dejme tomu ma cislo verze smysl, ale v Chrome ne - BFUcka to nezajima. Podle me se v tomhle desktopove aplikace priblizuji webovym - tam taky verze nikoho nezajimaji.