Front page | perl.perl5.porters |
Postings from January 2022
On Fri, 14 Jan 2022, 21:27 Leon Timmermans, <fawaka@gmail.com> wrote: > On Fri, Jan 14, 2022 at 1:15 PM demerphq <demerphq@gmail.com> wrote: > >> On Fri, 14 Jan 2022, 20:00 Darren Duncan, <darren@darrenduncan.net> >> wrote: >> >>> On 2022-01-14 3:40 a.m., demerphq wrote: >>> > On Fri, 14 Jan 2022 at 11:57, Darren Duncan wrote: >>> > I feel that Perl 5.36.0 SHOULD fix its own broken behavior >>> regarding stack >>> > traces. >>> > >>> > The 5.36.0 release is a major release and is far enough away that >>> DBIx::Class >>> > should be able to get fixed to not rely on the broken behavior in >>> time for its >>> > release. >>> > >>> > The fix shouldn't be put off another year. If anyone depends on >>> something that >>> > depends on the broken behavior, they should not upgrade past >>> 5.34.x until their >>> > other dependencies are updated for compatibility. >>> > >>> > I can live with that. >>> > >>> > I am not really convinced the patch really does break anything >>> however, we have >>> > been running with the fix backported for years and we never noticed >>> any issues >>> > with our DBIx class code. *shrug* >>> >>> That's all the more reason to re-apply the bug fix to blead right away. >>> >>> Your experience would imply that any reliance in DBIx::Class on the >>> broken >>> behavior isn't in its core functionality and more in some non-core >>> functionality >>> or alternately just a test is broken and main code isn't. >>> >> >> That would be my intuition, but I don't know that we use enough DBIx to >> be certain. But it's extremely hard for me to understand how such broken >> data could ever be truly useful. >> > > What breaks is a test that checks what modules are loaded by DBIx::Class. > The change in behavior causes it to make different conclusions as to who is > loading what. I suspect this is representative for the sort of code that > would be affected by this change. > But those assumptions are basically broken, so I'm not sure your point. Classic case of GIGO. Yves >Thread Previous | Thread Next