Názory k článku
LibreOffice přechází na nové číslování, po verzi 7.6 přijde LibreOffice 24.2
-
Filip JirsákStříbrný podporovatelU stabilních velkých aplikací jako je LibreOffice, prohlížeče, linuxové distribuce, ostatně i Linuxové jádro, se už dávno vydávají verze tak, že se vydávají v určitém pravidelném intervalu (nemusí být pravidelný s přesností na sekundu, klidně se to může posunout o několik dnů nebo i týdnů), a do té verze se dostanou všechny věci, které se za předchozí období dostali do stavu způsobilého k vydání. Sémantické verzování v takovém případě nedává smysl, protože nelze rozlišit major a minor verzi. Verzování podle kalendáře vám rovnou poskytne tu jedinou informaci, kterou to označení verze má, a to kde bude/byla vydána.
-
A opet, uplne mimo, ostatne jako ve 100% jirsakopostu ... u vsech aplikaci dochazi k vydavani novych verzi, ktere nejakym zpusobem vyznamne mneni funkcnost (hlavni verze) a k vydavani udrzovacich verzi, kde se resi chyby (vedlejsi cislo) a tahle informace u cislovani rok/mesic ... zcela chybi.
Samozrejme to plati prave treba pro ten kernel ...
Tudiz mr jirsak jako vzdy blaboli zcela mimo.
-
Filip JirsákStříbrný podporovatel
Nezklamal jste, zase píšete nesmysly.
Za prvé, sémantické verzování má tři čísla verzí – major.minor.patch. Vy jste pomotal minor a patch do jednoho.
Za druhé, jak jsem psal, co je významná změna (aby se měnila major verze) a co menší změna (aby se měnila minor verze) je arbitrární rozhodnutí toho, kdo o verzování aplikace rozhoduje. U velkých a stabilních aplikací, jejichž příklady jsem uváděl, nenajdete žádné objektivní kritérium, podle kterého rozhodnout, co je velká změna a co malá změna. Jediné, co by se dalo o verzování říct, je to, že podle striktního výkladu by se major verze těchto aplikací už nikdy neměnila, protože ty aplikace (a jádro) si nemohou dovolit udělat jednorázově nějakou výraznou změnu, která by nebyla zpětně kompatibilní a rozbila by to, co na nich závisí.
Speciálně pro kernel platí, že Linus zvedá major verzi v okamžiku, kdy mu připadá, že minor verze je zbytečně velká. Takže to nemá vůbec žádnou souvislost se změnami, které ta verze přináší. Nebo jaká velká změna podle vás byla mezi 5.19 a 6.0? V čem byla větší než změny mezi 5.18 a 5.19? Jaká velká změna byla mezi 4.20 a 5.0 a v čem se ta změna lišila od změn mezi 4.18 a 4.19 nebo 5.1 a 5.2? Ve skutečnosti už dlouho platí, že verze kernelu označuje jen čas, akorát to z ní není vidět. Protože „minor“ verze rostou do cca 20, kolem dvacítky se Linus rozhodne zvýšit „major“ verzi o jedna. A vývojový cyklus jedné verze je také přibližně stále stejně dlouhý, významné narušení dělají různé svátky či konference.
-
DannyStříbrný podporovatelA navic se zrovna u kernelu do "patch" verzi obcas dostavaji i veci, co tu a tam neco zmeni docela zasadne, tak ze to jde oznacit za nekompatibilni zmenu. Jakoze treba najednou si clovek musi includovat o jeden header file navic...
-
A jirsak opet zcela mimo ... jirsaku, cisilovani existuji tisice ruznych zpusobu, ze ty vubec netusis na tom nic nemeni.
Ty pochopielne nemuzes tusit, ze verze 4.30 znamena., ze je to patchnovana verze 4, stejne jako verze 5.1 je opatchovana verze 5, a klidne mohly byt vydany ve stejnou vterinu jedineho dne.
Jakpak se pozna verze 23/8/23 ... od verze 23/8/23 ??? Nj, kdyz na to ty nestacis ...
-
Filip JirsákStříbrný podporovatel
LibreOffice ovšem do teď používá sémantické verzování, proto jsem o něm psal.
Verze 4.30 může znamenat naprosto cokoli, co si autor toho čísla verze usmyslí. Když už píšete, že číslování existují tisíce různých způsobů, mohlo by vám dojít, že si každý může verze číslovat, jak chce.
To, že může být vydáno víc verzí stejného softwaru ve stejnou vteřinu je pravda, akorát je to v kontextu této diskuse nevýznamné. Ve stejnou vteřinu stejného dne budou moci být vydané klidně i verze LibreOffice 24.2.7 a 24.8.1. Například.
Jakpak se pozna verze 23/8/23 ... od verze 23/8/23 ???
Samozřejmě máte právo označovat verze, jak chcete, klidně si tam používejte třeba emoji. Akorát teda normální číslování verzí používá k oddělení jednotlivých komponent čísla verze tečku. A čísluje se tak, že každá verze programu má jiné číslo verze. Ale jestli vy chcete číslovat verze svého programu tak, že dvě různé verze budou mít stejné číslo, vaše volba. Tak nějak by to k vám i sedělo.Nejste vy náhodou bývalý uživatel „j“ a nezačal jste brát léky? Jéčko také vždy nejprve někomu vynadal, pak napsal několik hloupostí,a skončil zase nadávkou. Akorát teda jeho nadávky byly hrubší, než ty vaše – tak možná ta medikace aspoň trochu zabírá.
-
Pokud bude číslování jen podle data, pak může imho existovat jen jediná major verze. Ostatní verze pak můžu být třeba libreoffice-next, nebo tak libreoffice-legacy, ale ne libreoffice. Už teď mi z toho jde hlava kolem. Na druhou stranu, zrovna u libreoffice je mi to upřímně jedno, prostě se spolehnu na automatickou aktualizaci.
-
Ono číslování podle data vydání je super, pokud vydáváte kontinuálně (Continuous Delivery) a podporujete pouze jednu verzi. Typicky aplikace běžící v cloudu nebo by se to mohlo hodit Chrome/FF apod.
U ostatních to postrádá smysl, ale managementu se to lépe hodí do tabulek tj. nepotřebují převodní tabulku datum vydání<=>číslo verze, ale stejně musí mít tabulku verzi 24.2 podporujeme od–do např. 02/24–02/26. -
Filip JirsákStříbrný podporovatel
Mohly by jako major verzi použít celý rok (2023). Ale i tak by se určitě našly stránky, které by to rozbilo.
-
Filip JirsákStříbrný podporovatel
Ano, je to jak píšete. Na způsobu číslování se nic nemění, pouze se mění význam prvních dvou čísel – místo major a minor verze označují rok a měsíc plánovaného vydání té hlavní verze. Tj. verze plánovaná na únor 2024 bude mít první verzi 24.2.0, první opravná verze bude 24.2.1 (a může být vydaná klidně v červnu) atd. Teoreticky pokud by se přišlo na vážný problém při testování, může se klidně vydání verze 24.2.0 posunout až na březen, ale pořád to bude verze 24.2.0.
Není to nic nového, takhle je verzované třeba Ubuntu nebo produkty JetBrains.
-
Jenže zrovna v LibreOffice byl vždy přechod mezi major versemi dost významný - ať už se to týkalo omalovánek nebo funkčnosti. Obvykle to znamenalo, že jsem nějakou dobu (rok...) držel obě verse vedle sebe, dokud uživatelé prostě nepřešli na tu novější. Občas se to neobešlo bez nekompatibilit ve formátu či ovládání...
Tohle kalendářní číslování povede k tomu, že ta verse bude jen jedna - a čert pozná, kdy by bylo dobré mít vedle sebe dvě a kdy jen něco málo vylepšili...
Třebas v Ubuntu je ten systém poměrně jasný a přehledný. Tady bude potřeba počkat, jak se to vyvine. -
Filip JirsákStříbrný podporovatel
Je možné, že plánují i změnu vývoje, že se třeba takovéhle změny budou dělat po menších částech průběžně.
Nekompatibility formát jsou podle mne chyby. Nekompatibilita ovládání vznikne s jakoukoli změnou ovládání – proto je sémantické verzování neurčité, protože major verze se mění při významných nekompatibilitách. A co je „významná nekompatibilita“ je věc názoru.
-
Podle mého názoru je významnou
nekompatibilitou
, když to běžní uživatelé poznají buď při práci nebo na změněné funkčnosti připravených a dlouho užívaných šablon.
Ne, že by obvykle nestačilootevřít starý - drobně upravit rozpadlé objekty - ulořit nový
, ale přesně pro tyhle rychlé opravy je dobré mít ty verse pěkně vedle sebe.
Pokud by nastalo riziko, že taková věc můře nastat s kteroukoliv versí (takovéhle změny budou dělat po menších částech průběžně
), nezbyde, než mít ty verse dvě až tři vedle sebe neustále a updatovat pouze patchováním. -
Filip JirsákStříbrný podporovatel
když to běžní uživatelé poznají buď při práci
Jak jsem psal, to je pak zpětně nekompatibilní změna i to, že upravíte ikonu tlačítka. Nebo že přidáte úplně novou funkci, která nijak neovlivní současnou funkcionalitu, ale pro tu novou funkci přidáte nové tlačítko. Někteří běžní uživatelé si začnou stěžovat, že jejich funkce předtím byla na druhém tlačítku zprava a teď je třetí zprava… -
Filip JirsákStříbrný podporovatel
Ale to je právě ten problém – spousta uživatelů skousne velké změny, a někteří se šprajcnou při změně ikony. Jak pak chcete rozhodovat o tom, co je a co není velká změna? A k čemu je vám informace, že pro někoho jiného je nebo není to velká změna?
Rozházené číslování objektů chápu z vašeho popisu jako chybu, a k takové chybě může dojít v jakékoli verzi, klidně v patch verzi.
-
Rozbité číslování (i rozsypané obrázky) nebyly ani
chyba
, ale naopakvylepšení
, k kterému došlo právě s přechodem na novou versi: ve staré to ne zcela fungovalo a uživatelé to měli upravené poměrně šikovným návrhem šablony - což se tím vylepšením rozbilo. Oprava nebyla ani tak složitá - jen těch dokumentů bylo poměrně hodně.
A když jste postaven před starý dokument, který buď můžete postupně stránku po stránce opravovat, nebo otevřít ve starší versi aplikace a vytisknout (protože to snad nikdo už nebude potřebovat) a pro jistotu uložit do PDF (kdyby náhodou) - které řešení si vyberete? A které si vybere obyčejný uživatel?
Pro tyhle případy se právě hodí mít nějaký ten milník v záloze - a tím byla poslední verse předchozího majoru s vysokou mírou spolehlivosti. (Stejně tak Ubuntisti se rádi drží na LTS versích - protože vědí, které to jsou.)
Průběžné vylepšování je dobré pro prohlížeče - leč i tam se hodí záchytné ESR. Třeba něco podobného bude i u těch Office - uvidíme. Jen: kdyby se to číslování neměnilo, nemuselo by se právě tohle řešit. -
Filip JirsákStříbrný podporovatel
Pokud to číslování byla oprava chyby, mohlo to klidně být opraveno i v rámci patch verze. Např. proto, že by si autor té opravy myslel, že to drobně opraví nějaké okrajové případy a nenapadlo by ho, že někdo má na té chybě založený nějaký systém, který se mu opravou rozpadne.
To je nevýhoda sémantického verzování, že je to teoretický koncept, který v praxi ne vždy funguje, protože je založený na pojmech, které mají pro různé lidi různý význam.
Když je průběžné vylepšování dobré pro prohlížeče nebo pro jádro, proč by nemělo být dobré i pro kancelářský balík?
-
-
Me se to zda naprosto logicke. Take jsme pred lety presli na tento zpusob cislovani. Predtim jsme cislovali 1.1, 1.2, .. 7.1, 7.2 a kdyz se schylovalo k osme verzi, tak jsme preskocili na 7.90, 7.91, ... 7.99, 7.99a, 7.99b, protoze ta osmicka stale nebyla stabilni, az nas to prestalo bavit a zacali jsme cislovat 15.01.00, 15.02.00 a tak dale. Kdyz byly stejny mesic 2 verze, tak 15.02.01, 15.02.02 a tak dale. Kdyz se podivam, jakou verzi ma klient, vim okamzite, jak moc je stara, Kdyz ma nekdo prava na upgrade az do konce roku 2022, tak vim, ze posledni co muze instalovat je 22.12. Kdyz vidim, ze ma nekdo 17.06, tak vim okamzite, ze je to vykopavka a vim, ze v roce 19 byly zmeny zakonu, tak ta jeho verze vydava faktury, ktere nejsou formalne spravne. Proste tohle cislovani je podstatne prehlednejsi. Ja jsem pro.
