On 2020-06-27, at 6:27 AM, Daniel J. Luke wrote:
> On Jun 22, 2020, at 11:20 PM, Ryan Schmidt <[email protected]> wrote: >> On Jun 22, 2020, at 14:34, Daniel J. Luke wrote: >>> We should just have one perl5 port that tracks the current release. >> >> You say this every year (or at least often). > > I say this every time we run into the set of problems that we would solve by > moving to this method (that we continually avoid solving just kicking the can > down the road with the current solution - which is a huge amount of work that > we just have to repeat every time there's a perl release). > >> Are you volunteering to be the one to ensure that every port that uses perl >> is compatible with the new perl release when it comes out? Without someone >> to do that, blindly upgrading everything from say perl 5.28 to 5.30 will >> likely break ports. > > Every time we upgrade a library we 'blindly break ports' since we don't (and > can't) comprehensively test every combination of things. > > It sounds like your argument against doing this is "we want the ports tree to > be stable" which I don't think has been the case in the past (and if we /do/ > want it to be a stable tree, we shouldn't be doing may of the updates that we > do now). > >> Do you remember perl 5.26? It broke a lot of ports, requiring a lot of fixes >> like this to be added: >> https://github.com/macports/macports-ports/commit/454eb2b0608266ab7bdf51a82d690be0f97610fe > > I do, part of the pain with perl5.26 was that we waited a long time to update > things because everyone was afraid of fixing the things that were broken. > > I'll note that upstream already does test CPAN modules with new versions of > perl (and notifies their version of maintainers) - so the things that remain > broken are things that aren't actively maintained upstream (and if they > remain broken in our ports tree, aren't being actively maintained by us > either). > >> The strategy currently being employed by those volunteers who are >> maintaining the perl ports is to keep everything defaulted to 5.28 for now, >> add 5.30 ports and fix problems in them as they're found, and once >> everything is building then switch the default to 5.30. This seems sensible >> to me. > > Things get fixed faster when they're broken, I'd bet perl 7 (which is what > perl5.32 is going to be) will be out before we're moved to perl5.30 (of > course, perl 7 is going to break some backwards compatibility). I suspect the > fundamental disagreement here is that I'm more comfortable with breaking > things in the ports tree (and then fixing them) than you are. > > -- > Daniel J. Luke > So in the end, are we setting texinfo back to perl5.28 ? K
