|
|
|
|
|
|
by imrejonk
1543 days ago
|
|
|
> At the time when Debian 11 was about to be released, PHP 8.0 was 10 months old yet Debian's 11 was released with PHP 7.4. That makes PHP 7.4 the standard in Debian stable for at least 3 years after its release. But PHP 7.4 only gets upstream support until 28 Nov 2021 and security support is permanently ended at 28 Nov 2022, which is seven month from now. This means that unless Debian has some really good C developers, no one can provide any security fixes for PHP 7.4. Not only that, no one outside of Debian will be monitoring problems with PHP 7.4 because everyone else will long since have upgraded to PHP 8. It’s a case of bad timing. Packages for PHP 8 were uploaded shortly before the bullseye freeze, which didn’t sit well with the release managers. See bug #976811 [1]. The maintainer also mentions in that bug thread that Microsoft will provide security fixes for PHP 7.4 after the EOL date. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976811 |
|
|
But it doesn't work like that. Packages have reverse dependencies. Just updating PHP to 8.0 would have broken all reverse dependencies that didn't already support PHP 8.0. So it isn't just a case of shipping the newer version of PHP; all upstreams of reverse dependencies need to have shipped updated versions, too, and all of those need to have had their packaging updated.
In practice distributions patch support in to laggard reverse dependencies or even remove them to speed things up. But still, the actual work involved is much more than the naivety in the statement "PHP 8.0 was 10 months old yet Debian's 11 was released with PHP 7.4."
A second common misconception is that just because an upstream declares some kind of support period, distributions have to follow them or it's somehow a problem if they do not. Upstreams even having a declared support period is the exception, not the norm. Distributions have been declaring a support period for their release as a whole long before some upstreams started doing this.