Názory k článku
Firefox a Chrome se obávají problémů s trojcifernou verzí v řetězci User-Agent
-
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.
-
Filip JirsákStříbrný podporovatelOba vydávají opravu staré verze – samozřejmě s novým číslem minor verze. Vznikaly by z toho třeba verze 2022.02.17.2.
-
Filip JirsákStříbrný podporovatel
Myslím, že vydáním opravy staré verze bylo myšleno to, že se pro verzi 96.0 vydá oprava 96.0.1. Nicméně Firefox udržuje ESR verze, Firefox ESR 91.6.0 byla vydána 8. února 2022, stejný den byla vydána i standardní verze 97.0 (a mezi tím samozřejmě byly verze 92–96).
-
Filip JirsákStříbrný podporovatel
Ne, Firefox ESR nemá řešené verzování úplně jinak. Verze ESR vzniká na začátku tak, že se standardně vydaná verze označí zároveň jako ESR. Nebo-li je jedna číselná řada verzí Firefoxu, přičemž některé z těchto verzí jsou označené jako ESR.
-
Filip JirsákStříbrný podporovatel
ž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í.
-
Filip JirsákStříbrný podporovatel
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.
-
Filip JirsákStříbrný podporovatel
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.
-
Filip JirsákStříbrný podporovatel
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.
-
Filip JirsákStříbrný podporovatel
Spring má jednotlivé projekty číslované klasickým sémantickým verzováním. To verzování podle let se týká jen skupin projektů (třeba Spring Data), a vlastně nevím, co tohle číslo verze vyjadřuje.
-
Filip JirsákStříbrný podporovatel
Jenže jako verzi dependency dáváte právě ty konkrétní projekty se sémantickým verzováním. Projekt používá třeba Spring Data JDBC 2.3.1, nepoužívá Spring Data 2021.1.1, ve kterém je 17 různých projektů pro přístup k 17 různým databázím.
-
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. -
BobTheBuilderStříbrný podporovatelMicrosoft tohle řešil tak, že po Windows 8 následovaly Windows 10, protože ve starých (často Java) aplikacích byl test na začátek řetězce "Windows 9".
Tady ovšem tak triviální řešení dostupné není. -
BobTheBuilderStříbrný podporovatel
Protože některé Java věci přežily od W95/95SE/98 až do příchodu W10, nebo aspoň debilní test na jméno operačního systému (když začíná na "Windows 9", tak je to legacy...). Ale je to i tak jen odhad, proč Microsoft přeskočil Windows 9.
Možná až přílišná zpětná kompatibilita některých knihoven?17. 2. 2022, 14:32 editováno autorem komentáře
-
BobTheBuilderStříbrný podporovatel
Windows 1 jsem snad nikdy neviděl, až 2.11cz, měli jsme na tom PageMaker - takový počítačový pravěk. K tomu se jen tak nedostanou, když W10 nahrazují po 7 letech verzí W11.
-
Upřimě, každý kdo vytvoří kód, který si při čtení verze neporadí s přechodem od dvouciferné verze na třícifernou, zaslouží kopanec do intimních míst. Stejně jako ten, kterého napadlo převádět datum/čas z řetězce přímo a bez řádných kontrol či pojistek na integer*. Ikdyž toho by měli rovnou vyhodit. Z "wokna" :-D
* AV scanner MS exchange. Převáděl řetězec data/času ve formátu YYMMDDSSSS na 32 bitový signed integer a v roce 2022 nevyhnutelně přetekl.
-
Vždycky jsem si říkal, že to snad někde vyučují a ono, ano, vlastně vyučují. Nevím přesně jestli to má jméno, ale je to ten "minimalistický" přístup k vývoji alá "udělám přesně a jenom to co je předemnou, až bude potřeba víc, tak 'se' to udělá/přidá", Komunita vývojářů okolo Javascript/React (co vím) je toho plná.
A tak se vám například stane, že přijdete k API která nemá pro základní/hlavní entitu, okolo které je to celé postavené, vyhledávání podle více id najednou, protože se čekalo, až jednou bude něco takového nějaký klient potřebovat - takže API to neumí - vývojáři nemají čas - jiné deadlines a klient to tedy nemůže implementovat. Koho by napadlo, že by v mnoha-produktové centrální API mohl někdo vyhledávat podle více id? (to se opravdu stalo a není to tak dávno). No, hlavně že v nějaké knížce o API nějaký inteligent vymyslel, že stylové je si hezky ORM požádat o každou entitu zvášť. WTF OMFG ... A teď nás připojili na druhý takový genitální výtvor. Takže, nespadněte smíchy ze židle, entity se dají hledat jenom jednotlivě podle id a ne podle (nazvěme to kategorií) kategorie. Je to jako byste v eshopu hledali výrobek podle přesného id, podle data přidání nebo stránky. Genitální.
Dál už psát nebudu, protože to bez sprostých slov nejde. Tak jsem musel stahnout API stránkovanou do jednoho souboru a hledat si v tom sám grep/regexp. Good job. Ti lidi fakt nepřemýšlí ....
17. 2. 2022, 13:32 editováno autorem komentáře
-
L.Stříbrný podporovatel
To motáte dohromady dvě dost rozdílné věci. Jedna věc je zprasit parsování verze tak, že si neporadí se situací, kdy je číslo trojciferné. (Což mi přijde, že je složitější a pracnější udělat špatně, než to udělat dobře.)
A druhá věc je, jestli máme do API / aplikace implementovat funkcionalitu, která "by se možná mohla někdy hodit". Tady to je ve skutečnosti docela komplikovaná otázka. Strávit 50% vývoje na funkcích, které nikdo nikdy nepoužije, evidentně není moc efektivní přístup. Na druhou stranu, dělat jen přesně to, co je aktuálně požadováno a ani o ždibíček víc je zase druhý extrém, který člověka může lehce dostat do slepé uličky. Takže to chce zkušenosti a cit rozhodnout, kde ten design trochu rozšířit a kde to nechat na budoucnost. Třeba i v té formě, že to sice nenaimplementuji, ale design udělám tak, že to v budoucnu bude jednoduché rozšířit.
-
> L
No, tak možnost dotázat se na entity podle (multiple) id mi nepřipadne jako něco co "by se mohlo hodit", ale co je snad nejmasovější užití - kolik jste viděl systémů, které neustále a naprosto pracují vždy jen a pouze s jednou entitou? Já snad ještě ani jeden (ale jistě se nějaký krajní případ najde). A přitom implementace takového endpointu je v podstatě stejně triviální jako implementace endpointu pro dotaz nad jedním jediným "id". Takže ne, tu vaši pointu neberu. Takový chybějící endpoint buď lennost, nebo naprostá neznalost. Nebo oboje.
Takže to chce zkušenosti a cit rozhodnout, kde ten design trochu rozšířit a kde to nechat na budoucnost.
Což je tak zhruba to, co jsem napsal. (viz odstavec výše)
17. 2. 2022, 21:00 editováno autorem komentáře
-
Ono totiž třeba v REST API není moc jak hodně ID entit poslat. V url path těžko. Query param vypadá na první pohled pěkně než narazíte na omezenou velikost URL. Header možná, ale někde se headry nepoužívají a musí se nastavit gateway aby je propouštěla. Pak zbývá v body. No ale pak zase nejde použít GET a POST na vyhledávání zrovna není nejčistší.
-
aha, proto se začaly poslední dobou objevovat patvary, kdy data se cpou do hlaviček a různých obskurních míst, místo aby se to poslalo POSTem, jak se u bulk dotazů běžně dělá. Někdo si vyložil, že REST musí všechna vyhledávání dělat pouze přes GET.
Kde se bere ta definice čistoty? Dělám ve vývoji 30, možná 40 let ty cyklické změny toho, co je zrovna pevným pravidlem a nesmí se porušit vznikají jako houby po dešti.
Asi je dobré si osvěžit paměť jak vlastně REST jako termín vznikl a co vlastně tak zkratka znamená, https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm
-
nargStříbrný podporovatel
Třeba v definici na co v RESTu slouží POST a na co GET (PUT ...)?
viz. https://restfulapi.net/http-methods/#post , https://httpwg.org/specs/rfc7231.html#POST -
L.Stříbrný podporovatel
Já jsem dotaz na multiple entities podle id (!) potřeboval naposledy... no, to už bude dávno.
Navíc sám píšete "protože se čekalo, až jednou bude něco takového nějaký klient potřebovat", tedy evidentně se to API už nějakou dobu používalo a nikomu tahle funkcionalita nechyběla. Takže ne, tu vaši pointu neberu.
-
JmJStříbrný podporovatelA neni to treba tim, ze ten kdo nic jineho nez omezeny fw nezna, tak ani nic vic nepozaduje?
Ti co delaji s frameworky vzdycky reknou, ze to prece jde udelat nejak, takze prece neni problem. Neumime join pri dotazu? Prece to jde obejit.
Elegantni navrh aplikace podle selskeho rozumu jde do kopru, schopnosti nizsich vrstev se temer nevyuzivaji, vykon je spatny ci aspon diskutabilni a kdyz za rok skonci podpora, tak se to musi prepsat, nebo zacit udrzovat na vlastni naklady, takze co se na zacatku usetrilo, se zacina utracet.
Vseho s rozumem, nic se nema prehanet. Jen mam dojem, ze toho rozumu se nejak nedostava...
-
Filip JirsákStříbrný podporovatel
U nějakých legacy systémů, které běží na HTTP/1.1, se to může hodit. U nových systémů, které používají HTTP/2, je to klasická předčasná optimalizace, která nakonec věci akorát komplikuje a zpomaluje. Stačí jeden endpoint pro jedno id, když jich potřebuju víc, zavolám ten endpoint opakovaně. Nemusím vytvářet nový endpoint, bude dál fungovat kešování, data pro jednotlivá id bude dostávat postupně tak, jak jsou k dispozici – takže klidně můžu uživateli zobrazit 49 položek, se kterými on už může pracovat, a nemusí se čekat, až se táhne 50. položka, která třeba z nějakého důvodu trvá déle. Dál funguje i horizontální škálování, nemusí mi všechny položky vracet jeden server.
Takže takový chybějící endpoint není lenost nebo neznalost, naopak to může být znalost a používání moderních technologií.
-
JmJStříbrný podporovatel
To je tak, kdyz na vsechno je framework, ze kterych to prece slepime. A ten framework dela kde kdo, kdo ma do zadku diru. Coz by jeste bylo ok, kdyby nemel tu drzost cpat to ostatnim, jako to nej cool reseni.
-
Spis je na zamysleni ze programator musi myslet na nejake kontroly u takto primitivni ulohy. Tohle by mel mit kazdy system uz v sobe ze provede parsing do pozadovaneho formatu.Ted mame ze kazdy si to dela po svem a pak resime jestli ten nebo ten program nespadne.
Ale uz je pozde, uz to tak je, tak hold musi programator myslet i na takovou vec.
