Necekam ze by snad pouzita verze php byla podporovana celejch 5 let co je podporovana verzie debianu. Staci kdyz bude podporovana do ty doby, co vyjde nova verzie debianu, s novou podporovanou verzi php. Nic vic necekam, jen to, ze muzu vzdycky bezet na stabilim debianu, s podporovanou verzii php.
Stacilo pro debian9.0 vzit php7.1 (ktere vyslo o pul roku driv). Podpora pro php7.1 konci letos v prosinci, a tou dobou uz budeme mit debian10.0.
Bohužel se mezi Debianem 8 a 9 zrovna zároveň skákalo z verze 5.x na verzi 7.x, a kompletně nový systém toho, jak je PHP zabalíčkované. E_TOOMANYTARGETS
I pro Debian 10 to s PHP 7.3 nebude nijak slavné a to okno na přechod z PHP 7.3 na cca PHP 7.5 bude maximálně půl roku. A představte si, že někde mají ještě pořád (jako právě teď) problém s předchodem "jenom" na PHP 5.6.
Prostě cílem není uspokojit všechny, ale jenom to mít méně rozbité pro většinu uživatelů, což Debian Stretch splňuje, včetně toho, že PHP 7.0 v Debian stretch je stále podporované ze strany Debianu.
Způsob, jak toho dosáhnout, je snadný – přestat s něčím, co se až příliš vznešeně nazývá „backportování bezpečnostních chyb“ a používat místo toho aktuální upstream verze. (Mimochodem, přesně tohle – aktualizujte, aktualizujte, aktualizujte – se už hezkých pár let vtlouká do hlavy všem, kdo mohou ovlivnit používanou verzi softwaru, od uživatelů Windows 10 Home po správce).
Ono to samozřejmě má i svá negativa, z nichž největší je to, že konzervativci mají mnohem raději jistotu svých starých známých chyb než riziko, že by je snad mohly postihnout chyby nové. V enterprise sféře je to dokonce vyžadovaný přístup, a i když už je za svým vrcholem, stejně tu ještě nějakou dobu bude. Nicméně už je jisté, že je tento přístup překonaný, protože nestíhá držet tempo s okolním světem. Tím, jak se toho stále více provozuje „aaS“, bude tenhle přístup udržování starých verzí čím dál hůře obhajitelný. Protože provozovatel té „S“ musí držet krok s konkurencí a nabízet nové služby, a nebude si komplikovat život udržováním zpětné kompatibility několik let.
Takže otázka není, zda se přejde na průběžné aktualizace, ale kdy se na ně přejde a v případě distribucí hlavně jak dobře ten přechod zvládnou. Poptávka po tom je velká, stačí se podívat na úspěch Dockeru – sice je nebezpečný, navržený trochu divně, ale lidi ho přesto používají. Přičemž důležitým důvodem (který je schovaný i za spoustou jiných důvodů) je právě ta možnost používat aktuální verzi aplikace.
Jasně, protože například přechod na PHP 7.3 vůbec neznamenal, že nepřestaly fungovat extensions z PECL (některé důležité nefungují dodnes), nepřestaly fungovat například části symfony frameworku (kde mimochodem pořád není aktualizace) nebo třeba horde, atd.
Pokud PHP nezačne nabízet nějakou LTS verzi, tak to bude vždycky některým směrem nahnuté. Buď vydáte s verzí PHP, kde buď samotné PHP nebo ekosystém okolo bude trpět dětskými chorobami, nebo to bude vždycky trochu pozadu.
Jenže hlavní důvod, proč ty extensions přestaly fungovat, je ten, že se přece všude používá stará verze PHP, používá ji i autor té extenze, takže podporu nové verze „nikdo“ nechce a pro autora by bylo komplikované to upravit.
LTS verze je právě úlitba těm, kteří chtějí držet staré verze, když se přechází na rychlejší model vývoje. Uznávám, že mají význam alespoň v tom, že se pak víc lidí sjednotí na té jedné staré verzi a ta se udržuje hromadně – ale stejně je to jenom úlitba těm, kteří z nějakého důvodu nemohou naskočit hned na rychlejší vývoj. Nikomu bych ale nedoporučoval spoléhat na to, že tu LTS verze budou věčně – je to jenom odklad.
Ekosystém kolem PHP nemusí trpět dětskými chorobami – akorát se musí naučit, že ta správná verze, se kterou má všechno fungovat, je nejnovější verze, ne ta nejstarší ještě podporovaná (a nebo taková, která už není podporovaná, ale teprve krátce). Ono je to nakonec docela jednoduché, protože na tom, která verze je nejaktuálnější, se všichni shodnou (na rozdíl od toho, která stará verze je ta správná), a když se něco rozbije, tak se to v příští verzi opraví.
Samozřejmě, že to bude bolet, zvlášť když zrovna ekosystém PHP byl dlouho zvyklý jet v tom režimu, že se na nějakém serveru najde nějaká použitelná kombinace verzí, a pak je to tam do té doby, než ten webhosting nezanikne a ti lidé nezaloží nový webhosting, kde použijí udělají to samé s novější verzí PHP. Ale jiná možnost není. A když se teď do toho pustil i Oracle s Javou, dá to i PHP :-) Jinak samozřejmě cesta je alespoň po přechodné období podporovat víc verzí (jak to ostatně lepší webhostingy dělají).
@Filip Jirsák
To se lehce píše, ale lidi nejsou a poslední verze php přináší celkem razantní změny. Ony by ty verze na tom jednom hostingu i byly, ale firmy nemají lidi na normální vývoj, ne tak na neustálé přepisování už jednou napsaných fungujících věcí. U php je to celkem v pohodě, ale jak začneš odřezávat security updaty, tak jde do tuhého. Radši bych to viděl tak, že si změny pořádně rozmyslí (ne že by to nedělali) a najednou teda změní všechno co je potřeba a není zpětně kompatibilní. A takovou verzi označit na pár let za LTS. Tento rychlý vývoj je super když někdo chrlí nové a nové menší věci, ale na udržování stovek různých instancí webů to není úplně vhodné. Viděl bych to jednoznačně LTS, to nejsou výmluvy, ale stabilní prostředí.
Už vím, co znamená knížecí rada. A dokonce už chápu, proč Marie Antonietta byla popravena za podobné druhy rad.
Jediná možná cesta, jak se zbavit problémů s PHP, je nepoužívat PHP. Jiná cesta není. Autoři PHP totiž mají pohrdlivý přístup ke zpětné kompatibilitě, a milují neustálé zbytečné nekompatibilní změny.
Nejlepší cesta by bylo buď donutit autory PHP chovat se slušně, nebo PHP vyřadit a nahradit jiným jazykem a nástrojem. Cokoli jiného je nefunkční.
Aby si všichni neustále přepisovali PHP skripty podle nových a nových verzí - to je jednak nesmysl, jednak ekonomicky neúnosné, jednak to zavádí zbytečné nové chyby a zranitelnosti do skriptů.
Uz to vidim, mas server na nom ti nieco funguje. Pustis update a zrazu to nefunguje. To je presne to co ocakavas od LTS server distra. Ked chces nasad si 'SID-a' ked sa rad zabavas, s nim je sranda. A budes mat PHP updaty kazdy tyzden.
Ja napriklad na firemnom desktope pouzivam TESTING a na notebooku SID-a. Ale to je moj desktop a staram sa on sam. Ked si predstavim ze by som sa mal starat takto o 170 virtualok tak to by som si asi hodil.
Palo: To je ale manipulace, protože to, že něco přestane fungovat, nezávisí na updatu, a už vůbec ne na tom, jestli se updatuje na aktuální upstream verzi nebo starou verzi opatchovanou distribucí. Rozbít se to může i tím, že se prostě jen začne projevovat chyba, která tam byla vždy, nebo se změní okolí – třeba webová služba přestane podporovat TLS 1.2. A k rozdílu mezi aktuální upstream verzí a distribuční patchovanou verzí – uvědomte si, kolik lidí testuje tu upstream verzi a kolik tu speciální distribuční verzi; a že v upstreamu ty chyby opravují vývojáři dané aplikace, zatímco tzv. „bezpečnostní záplatu“ často dělá správce balíčku v dané distribuci, který kód té aplikace nezná a možná ho dokonce při patchování vidí poprvé v životě. S tímhle backportováním „bezpečnostních záplat“ je spousta práce, ovšem podle mého názoru je dnes výsledek většinou horší, než kdyby se stejná energie věnovala aktuální verzi. Ona to není náhoda, že prohlížeče nebo Windows 10 přešly na model průběžných aktualizací – udržování starých verzí je prostě příliš nákladné a vede to k většímu množství chyb v bázi nainstalovaných programů.
Debian Testing je něco jiného, tam není účelem neustále udržovat stabilní aktuální verze programů. Já to řeším tak, že software postupně migruju do kontejnerů. Od distribuce pak už požaduju jenom stabilní aktuální základ systému (jádro + systemd + kontejnery + základní knihovny a utility), což řeší třeba CoreOS nebo Fedora Atomic.
Abychom si rozuměli, já jsem nikde nepsal, že to bude lehké, a zrovna to PHP je v tomto směru snad to nejnáročnější, co může být (ani ne kvůli samotnému PHP, ale spíš proto, kde, jak a kdo ho používá). Můj komentáři byl o tom, že k téhle změně stejně dříve či později musí dojít – navzdory tomu, že to bude náročné.
Samozřejmě k tomu patří i to, že zpětná kompatibilita je pak nějakou dobu udržována přímo v těch aplikacích, tj. nějakou dobu lze se starší verzí vydržet. Což znamená změny i na straně vývoje, už se nemohou dělat major verze, kde se všechno rozbije. A to je samozřejmě zodpovědnost upstreamu.