Podle mě by stejný problém nastal i u jiného číslování. Prostě jsou některé ty knihovny napsané špatně, to není chyba vývojářů prohlížečů, že svou práci odflákli vývojáři knihoven chybně detekujících verzi. Ve zprávičce se píše, že to nastalo už při přechodu z verze 9 na 10.
Nějak se číslovat musí a pokud by verze byla 9.999 a přecházelo by se na 9.1000 nebo 10.0, tak by u špatně napsaných knihoven problém přišel. Já naopak oceňuji, že se o to vývojáři prohlížečů zajímají předem, i když by nemuseli. Mohli by pak jen říct: my to máme správně, vy neumíte pracovat s řetězci.
že ty máš potřebu se pořád o všem dohadovat.
A že vy máte potřebu se pořád o všem dohadovat a ještě to psát špatně.
ESR si žije vlatní životem
Ne, číslování verzí má společné se základní verzí Firefoxu. Firefox 91.6.0 je z hlediska funkcionality pořád starší, než Firefox 92.0 – bez ohledu na to, že vyšla později než 92.0. ESR je jenom označení těch hlavních verzí, které ty dílčí aktualizace dostávají podstatně déle, než standardní verze.
portují se do ní všechny změny z hlavní větve
Ne, neportují, pak by ESR verze neměla žádný význam.
minor verze pak jedou úplně nezávisle
Ne, nejdou. Z hlediska funkcionality je to pořád jedna řada. V 91.1 je novější funkcionalita, než v 91.0. V 92.0 je novější funkcionalita, než v 91.1.
není to prosté přejmenování Firefox verze
Není to žádné přejmenování, prostě jen některé verze dostanou navíc nálepku ESR. Firefox 91.0 byl vydán jenom jednou, ale mohl jste si vybrat, zda při aktualizacích chcete zůstat u hlavní verze 91 (protože v této hlavní verzi budou vydávány aktualizace dlouhodobě, to je označení ESR), nebo zda chcete přejít na další hlavní verzi (tedy 92), jakmile vyjde.
Teď v únoru vyšel Firefox 97 a k němu Firefox 91.6 ESR, mají spousty společných změn, ale namátkou třeba ESR verze nemá opravený bug https://bugzilla.mozilla.org/show_bug.cgi?id=650091 nebo mají rozdílné verze PDFjs (v 91.5 ho revertovali na starší verzi). ESR je prostě jiné sestavení, ve zdrojovém kódu to mají také oddělené a jejich dílčí změny jsou jiné než ty v hlavní větvy.
Jednou za čas se vydá nová ESR, která to zase sjednotí a pak si ESR jede svým životem a její minor verze jsou backporty z hlavní větve, ale kódově často jiné, změněné, osekané. Takže ano, změny se tam portují.
Však se můžeš podívat sám, tohle je třeba kód určený pouze pro ESR https://phabricator.services.mozilla.com/D135086 v hlavní větvy Firefoxu se nikdy neobjevil a neobjeví.
ESR je klasická branch. Vydají verzi 91.0.0, ta je standardní a zároveň ESR. Pak se třeba vydá ještě opravná verze 91.0.1, opět standardní i ESR. Pak už se do hlavní větve přidávají nové funkce, ty se vydají jako nová standardní verze 92, ale ta branch 91 je dál udržovaná jako ESR verze a backportují se do ní opravy chyb. Po nějaké době se rozhodne o vzniku další ESR verze třeba z verze 102. Ta se nebude zakládat na té ESR verzi 91, nýbrž vznikne zase jako branch z aktuální verze 102. Těch ESR verzí může být vedle sebe dokonce několik – Firefox má jen čtvrtletní překryv, ale třeba linuxové jádro má těch LTS verzí několik souběžně.
Není to žádný oddělený kód, jak v případě linuxového jádra tak v případě Firfoxu je to klasická vývojová branch, kdy se v jednom okamžiku vydá z hlavní větve verze, o které se prohlásí, že bude dlouhodobě podporovaná. V tom okamžiku je tedy hlavní i dlouhodobě podporovaná verze úplně to samé, může se takhle vydat ještě několik opravných verzí, a teprve když se do hlavní verze začnou přidávat nové funkce, tak se to odštěpí a do té dlouhodobě podporované verze se jenom backportují opravy (typicky – ve skutečnosti se občas backportuje i nová funkcionalita a občas se naopak nebackportují ani opravy; ale základní smysl té verze s dlouhodobou podporou je, že se jen backportují všechny opravy). Nové hlavní verze s dlouhodobou podporou nevznikají s předchozích verzí, ale vždy se znovu odštěpí z hlavní větve. Staré verze s dlouhodobou podporou postupně zanikají, prostě se do toho branche přestanou přidávat nové commity a přestanou se z něj vydávat nové verze.
Do verze s dlouhodobou podporou se samozřejmě může dostat i nově napsaný kód – pokud je to jednodušší pro opravu nějaké chyby, protože kód v hlavní větvi už se příliš vzdálil a backportování opravy by bylo pracnější, než tu opravu napsat znovu přímo pro ten starý kód.
ESR je klasická branch. Vydají verzi 91.0.0, ta je standardní a zároveň ESR. Pak se třeba vydá ještě opravná verze 91.0.1, opět standardní i ESR. Pak už se do hlavní větve přidávají nové funkce, ty se vydají jako nová standardní verze 92, ale ta branch 91 je dál udržovaná jako ESR verze a backportují se do ní opravy chyb. Po nějaké době se rozhodne o vzniku další ESR verze třeba z verze 102. Ta se nebude zakládat na té ESR verzi 91, nýbrž vznikne zase jako branch z aktuální verze 102. Těch ESR verzí může být vedle sebe dokonce několik – Firefox má jen čtvrtletní překryv, ale třeba linuxové jádro má těch LTS verzí několik souběžně.
Skvělé! Takže si rozumíme a ty backporty tedy nastávají a dělají se pro ESR, samotná Firefox si naopak jede svým životem pořád dopředu a nikdy zpětně neaktualizuje předchozí vydání a vydává pořád vyšší a vyšší verze dopředu.
Pokud to je v jiné branchi, beru to jako oddělený kód, není to prostě v hlavní větvy a nedostane se to do Firefoxu.
Takže si rozumíme
Abych pravdu řekl, pořád si nejsem jist, že tomu rozumíte, protože o tom pořád píšete zmateně.
ty backporty tedy nastávají a dělají se pro ESR
Ano, to je princip LTS či ESR verzí, že se tam backportují opravy. To se vám snažím vysvětlit od začátku.
samotná Firefox si naopak jede svým životem pořád dopředu a nikdy zpětně neaktualizuje předchozí vydání a vydává pořád vyšší a vyšší verze dopředu
Předchozí vydání zpětně neaktualizuje snad nikdo. To, že se vydávají novější verze s menším číslem, než je nejnovější číslo verze, dělá Firefox i mimo ESR verze – vydává beta a developer edice, které jsou o verzi napřed, a nightly edici, která je o dvě verze napřed. Takže verze 98.0beta byla vydána 8. února (stejný den byla vydána i 97.0), ale až 17. února byla vydána číslováním „starší“ verze 97.0.1.
Zkrátka co se týče funkcionality, čísla verzí pořád rostou. Ale chronologicky to neplatí, verze s nižším číslem verze se běžně vydávají později, než vyšší číslo verze. Jenom v rámci jedné větve (standardní Firefox, ESR, beta, developer, nightly) platí, že verze seřazené chronologicky mají vzestupné číslování.
Pokud to je v jiné branchi, beru to jako oddělený kód, není to prostě v hlavní větvy a nedostane se to do Firefoxu.
To je hezké, že vy to tak berete. Vývojáři ovšem berou celé repository jako jeden kód. Běžně je v repository spousta vývojových branchů, které se následně mergují do release branchů. Backporty oprav se do hlavní větve dostávat nemusí, protože už tam obvykle jsou. Proto se to jmenuje backport, protože se to z hlavní větve portuje někam dozadu do předchozích verzí.
To je samozřejmě pravda, ale zase to znepřehledňuje rozdělení na major a minor verze, nehledě na to, že Tvoje schema neumožňuje vydat opravnou verzi v ten samý den.
No a co se týče parsování, pokud někdo nedává \d+ nebo podobný pattern, ať to raději nedělá vůbec. Děsím se, co by udělal s verzí typu 2022.02.31, pokud by mu odněkud přišla.
Hloupé u tohohle číslování je, že musíte dopředu přesně vědět, kdy která verze vyjde. Nebo to používat jen jako identifikátor nezávisle na skutečném datu, ale to je hodně matoucí.
Když už to souvisí s datem, je lepší formát RRRR.X, kdy se prostě číslují verze v daném roce od nuly nebo od jedné. Velkých verzí za rok se obvykle vydá méně než dvacet. Nicméně ten problém s řády by tam byl stejně, protože typicky by se nevydalo víc než .9, ale pak by se třeba někdy vydala verze .10 a byl by to znova problém. Navíc by to byl problém i teď, kdy by se zase přecházelo z verze 9x na verzi 2022.
Mě je docela jedno jaká verze knihovny se kde používá, když mě zajímá jenom jestli jsou spolu kompatibilní a to mi právě dependency na bom se Spring Data 2021.1.1 poskytuje. Nikde nemám definovanou jakou verzi např. Spring Data JDBC se používá, ta se bere z bomu resp. podle Springu z release train. Stejně tak vás (většinou) nezajímá, že když použijete Spring Boot tak, že tam je knihovna SnakeYAML ve verzi x.y.z.
Člověk by si myslel, že se z toho člověk už vzpamatoval, když jsme tu měli už stejný problém právě verzí z 9 na 10.
Tím prvním byla právě Opera. Ta to vyřešila poněkud kontroverzně. Zmrazila zápis Opera/9.80 a přidala zápis Version/1X.XX. Takže, kdo se tomu dokázal přizpůsobit, tak ukazoval správnou 10+ verzi. U ostatních "špatných" to už navěky ukazovalo 9.80.