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.
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.
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čilo otevří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.
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…
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 naopak vylepš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.
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?