https://salsa.debian.org/php-team/p...ebian/changelog
URL: https://www.overclockers.at/linux/clear-linux_255611/page_3 - zur Vollversion wechseln!
das php 5.6 hast jetzt aber du aus dem Hut gezaubert, das hat vorher keiner gesagt
PHP 5.6 wird noch immer über Extended LTS unterstützt. Das letzte Update ist vom 29. Sept. 2022:
https://salsa.debian.org/php-team/p...ebian/changelog
Zitat aus einem Post von PhilippPHP 5.6 wird noch immer über Extended LTS unterstützt. Das letzte Update ist vom 29. Sept. 2022:
https://salsa.debian.org/php-team/p...ebian/changelog
Zitat aus einem Post von davebastarddas php 5.6 hast jetzt aber du aus dem Hut gezaubert, das hat vorher keiner gesagt
Das Problem hat man praktisch mit jeden neuen PHP Version. Bei PHP 8.2 gibt es auch wieder neue Kompatibilitätsprobleme weil immer etwas geändert wird, anstatt zu schauen das es Kompatibel zu alten Scripten bleibt.
Beim Wechsel von PHP 5.6 auf 7.0 hat man ja überhaupt das alte MySQL Modul entfernt, das damals ein Großteil der damaligen Scripte verwendet hat. Stattdessen musste man dann MySQLi mit etwas anderen Syntax verwenden 
Zitat aus einem Post von Philippanstatt zu schauen das es Kompatibel zu alten Scripten bleibt.
Die Rueckwaertskompatibilitaet von PHP - und vieler anderer, ebenfalls erfolgreicher, Sprachen - ist dennoch unterm Strich lachhaft schlecht. Wenn man sich da im Vergleich Perl5 (wobei die Maintainer gerade ueberlegen, aus Komfortgruenden schlechter zu werden, bzw. das tw. schon geworden sind), TCL oder Pascal-Dialekte wie FPC ansieht, erkennt man gut, wie es laufen KOENNTE, wenn die Entwickler-Teams sich einen Dreck um diese Eigenschaft scheren wuerden. Aber nein - ist ja wurscht, wenn man Downstream zigtausende Arbeitsstunden durch irgendwelche hippen Schnapsideen verbrennt 
Evolution muesste nicht immer gleichbedeutend mit (am Ende dann sich oft mehrfach selbst ausloeschender) Revolution sein.
Naja, da gibts halt spezielle Anforderungen. Wir haben über 100 Software Appliances in Betrieb, Security Fixes werden automatisch eingespielt via unattended-upgrade, automatische Reboots durchgeführt wo notwendig, und wir setzen dort Debian LTS mit PHP 7.1 ein.
Das nächste Rollout ist dann halt rechtzeitig vor dem LTS-Ende und inzwischen können sich die Kunden auf reibungslosen und sicheren Betrieb verlassen.
Für solche Szenarien ist Debian extrem gut geeignet und kann überragende Stabilität vorweisen. Unsere Devs wissen entsprechend, für welches PHP sie entwickeln.
Für den Desktop seh ich das wenig relevant, da hab ich gerne aktuelle Pakete aber ohne mir mit Bleeding Edge regelmäßig das System zu zerschießen. Auf regelmäßige große Upgrades hab ich auch wenig Lust.
PHP 7.4 ist im Herbst aus dem Support gefallen - ja debian macht Backports aber das heißt nicht dass man auf der sicheren Seite ist.
Wenn die Applikation wichtig ist wird sich wohl Geld finden diese aktuell zu halten. Wenn nicht dann kann mans wohl abdrehen
@Colo ja eh man könnte da mehr machen, zB Feature Flags auch direkt bei der Sprache verwenden
Zitat aus einem Post von COLOSSUSWenn man sich da im Vergleich Perl5 (wobei die Maintainer gerade ueberlegen, aus Komfortgruenden schlechter zu werden, bzw. das tw. schon geworden sind)
Das ist ja transparent welche Security Issues PHP veröffentlicht und wann das vom LTS Team backported wird. Also ich bekomme regelmäßige E-Mails dazu und sehe eigentlich, dass das konsequent abläuft.
Zitat aus einem Post von nexus_VIDas ist ja transparent welche Security Issues PHP veröffentlicht und wann das vom LTS Team backported wird. Also ich bekomme regelmäßige E-Mails dazu und sehe eigentlich, dass das konsequent abläuft.
Warum soll das nicht sicher sein? Das ist die aktuellste Version von PHP die von Debian Stable unterstützt. PHP 8.2 kommt erst mit Debian 12 im Sommer.Zitat aus einem Post von Viper780PHP 7.4 ist im Herbst aus dem Support gefallen - ja debian macht Backports aber das heißt nicht dass man auf der sicheren Seite ist.
Es wird alles dokumentiert. Da muss man auch nicht in den alten Versionen suchen, sondern portiert Bugfixes aus neuen Versionen zurück in die alten Version.Zitat aus einem Post von Viper780Es wird halt in alten PHP Versionen nicht nach Issues gesucht
Ich kenn dass sehr sehr gut 
Die Backports gelten halt nur für Bugs in höheren Versionen.
Wenn jetzt zB was in 7.4 steckt dass in 8.2 nicht auftritt (durch die andere Code Basis) dann wird danach nicht gesucht und auch nicht gepatched.
Dass ist so wie wenn wer Log4j v1 einsetzt weil die nicht im CVE steht
overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2025