randomly bumping things to require perl 5.30 vs 5.28 requires everyone to have both installed ...

[Ken Cunningham]

On 2020-06-27, at 6:27 AM, Daniel J. Luke wrote:

> On Jun 22, 2020, at 11:20 PM, Ryan Schmidt <ryandesign at macports.org> 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