Hi Ondřej On 2021-01-12 12:40:22, Ondřej Surý wrote: > I guess we are going to release with PHP 7.4 then. Not the ideal choice, > but I will do whatever I can to support it. > > However, I would like to get an official statement from the release team > what's their position, so we can go forward. Pretty please? > > Also an advice on how to proceed next time this happens. The timing of our > freeze and new PHP release coincidentally goes together. Should I start the > transition with alpha/beta/rc instead of the first final release?
The timing is not ideal and there are still quite a bunch of blocking bugs open. Given also list of autopkgtest regressions reported for the php-defaults version in experimental, I'm not even sure if all of them have been reported to the BTS. I'm also CCing the security team for their input in case the have a strong opinion on this transition. To avoid the same situation for the bookworm freeze, I think staging the transition early in experimental with alpha/beta/rc version with the corresponding php-defaults change would make sense. This would help to get most of the FTBFS bugs and autopkgtest regressiones reported and would give the maintainers time to fix them beforehand. Cheers and sorry for not replying earlier. > > > Ondrej > > On Fri, 11 Dec 2020 at 18:01, Ondřej Surý <ond...@sury.org> wrote: > > > The main problem is the PHP release schedule: > > https://www.php.net/supported-versions.php > > > > If we release with PHP 7.4, the upstream security support will end sooner > > than security support for Debian bullseye. If we release with PHP 8.0 we > > will have full three years of upstream support. > > > > There’s still month before the transition freeze and we will have time to > > fix the downstream users after the transition is over. > > > > I think the transition is worth the trouble. Having official security > > support is important especially for PHP. > > > > Ondřej > > -- > > Ondřej Surý <ond...@sury.org> (He/Him) > > > > On 11. 12. 2020, at 17:38, David Prévot <taf...@debian.org> wrote: > > > > Hi Ondřej, > > > > Le Tue, Dec 08, 2020 at 09:28:38AM +0100, Ondřej Surý a écrit : > > > > I would like to transition the PHP to version 8.0; > > > > > > The timing of this request makes me uneasy: php8.0 has been in Debian > > for less than a week, and we are a month away from the transition > > freeze. > > > > it's not such a huge bump as it was with 5.6 -> 7.0 and > > > > > > If I remember correctly, the 7.3 -> 7.4 was not a huge bump either, yet > > php7.4 packages were in Debian months before the actual transition > > happen, and it took months for the updated php-defaults to actually > > migrates into testing. > > > > most of the packages that were compatible with PHP > > > > 7.4 are working just fine with PHP 8.0. > > > > > > That does not match my experience as a maintainer of about a hundred > > packages relying on PHP. Many upstream are currently releasing updates > > to fix compatibility with PHP 8.0, and many more have not yet done so. > > > > I’m actually surprised to discover this request in the BTS without any > > prior communication with teams involved in PHP related packaging. > > > > For example, PHPUnit 8 as currently available in unstable and testing is > > expected to run on PHP 8 (thanks to upstream updates less than two weeks > > ago), yet “Please note that the code coverage functionality is not > > available for PHPUnit 8.5 on PHP 8.” (from upstream changelog 8.5.12). > > So shipping PHPUnit 8 with PHP 8 would mean having a major > > fonctionnality unavailable for the whole Bullseye life cycle. PHPUnit 9 > > is available from experimental, yet uploading to unstable would mean > > having to deal with dozens of breakage (in the FTBFS form): > > > > https://release.debian.org/britney/pseudo-excuses-experimental.html#phpunit > > > > PHPUnit is just one example, but it seems unrealistic to ship version 9 > > with Bullseye (I really abandonned this option months ago). Other > > packages will break (and I suspect the number of breakage will be high). > > > > This kind of disruptive change would hopefully be better suited early in > > the release cycle rather than just before the beginning of the freeze. > > > > That said, it would be nice to have an updated php-default in > > *experimental* to help have a grasp of the possible brekages. > > > > Regards > > > > David > > > > -- Sebastian Ramacher
