This morning, May 14th, Nicholas, Neil, and I had the weekly PSC call. Here's a brief overview of topics discussed:
*v5.34.0* — A few bumps, but we're going well.
We plan to apply 18782 <https://github.com/Perl/perl5/pull/18782> to address some build failures. This will go in after practical testing on Windows or in two days, whichever comes first. (Unless it breaks.)
In 18793 <https://github.com/Perl/perl5/pull/18793>, you can see Nicholas's plan for Data::Dumper: revert the version in blead before v5.34.0, release a patched version to CPAN, import to blead after it's firmly believed to be safe.
MinGW.org breakage from 18510 <https://github.com/Perl/perl5/issues/18510> is not being treated as a blocker for v5.34.0. We may apply the fix before v5.34.1, but the impact of this issue is believed to be of little practical impact.
*Platform Expectations and C99*
We've talked about platforms before: what might it mean for us to have a list of "Tier 1" platforms? How do we know when we can delete code for building on MS-DOS? The three of us spent a long time talking about this and reviewing the way other systems answer this question, and felt like we ended on common ground. Nicholas will be leading some discussion about this on p5p.
Meanwhile, and tied up with that, was the perennial question of "what C99 stuff can we use?" We think the answer is "more than we use right now," but it's tied up with platforms. If we think that mixing declarations and code would make our lives easier, then we should do it… unless it means we can no longer ship Perl to FreeBSD. For example. Since the two topics are linked, expect Nicholas on this one, too.
*Backward Compatibility Issues*
Is the specific structure of the optree something we promise remains stable? What about the specific behavior of various hook functions? Perl has a lot of things that get treated like they're set in stone, then people build on them, then we're in the awkward position of being unable to improve them. We want to get better at signaling what can or can't be relied upon. I wrote down some notes, but I don't think anybody should be holding their breath on action for this yet.
--
rjbs
*v5.34.0* — A few bumps, but we're going well.
We plan to apply 18782 <https://github.com/Perl/perl5/pull/18782> to address some build failures. This will go in after practical testing on Windows or in two days, whichever comes first. (Unless it breaks.)
In 18793 <https://github.com/Perl/perl5/pull/18793>, you can see Nicholas's plan for Data::Dumper: revert the version in blead before v5.34.0, release a patched version to CPAN, import to blead after it's firmly believed to be safe.
MinGW.org breakage from 18510 <https://github.com/Perl/perl5/issues/18510> is not being treated as a blocker for v5.34.0. We may apply the fix before v5.34.1, but the impact of this issue is believed to be of little practical impact.
*Platform Expectations and C99*
We've talked about platforms before: what might it mean for us to have a list of "Tier 1" platforms? How do we know when we can delete code for building on MS-DOS? The three of us spent a long time talking about this and reviewing the way other systems answer this question, and felt like we ended on common ground. Nicholas will be leading some discussion about this on p5p.
Meanwhile, and tied up with that, was the perennial question of "what C99 stuff can we use?" We think the answer is "more than we use right now," but it's tied up with platforms. If we think that mixing declarations and code would make our lives easier, then we should do it… unless it means we can no longer ship Perl to FreeBSD. For example. Since the two topics are linked, expect Nicholas on this one, too.
*Backward Compatibility Issues*
Is the specific structure of the optree something we promise remains stable? What about the specific behavior of various hook functions? Perl has a lot of things that get treated like they're set in stone, then people build on them, then we're in the awkward position of being unable to improve them. We want to get better at signaling what can or can't be relied upon. I wrote down some notes, but I don't think anybody should be holding their breath on action for this yet.
--
rjbs