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

[Ryan Schmidt]

On Jun 22, 2020, at 23:00, Jason Liu wrote:

> On Mon, Jun 22, 2020 at 11:21 PM Ryan Schmidt wrote:
> 
>> I've just realized this discussion has been to the old list address from macosforge. Please always use the new list addresses at lists.macports.org.
>> 
>> 
>> 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).
>> 
>> 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.
>> 
>> 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
>> 
>> 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.
> 
> Would it be possible to sort of split the difference? i.e. not _just_ have one single perl5 port and get rid of all the individual point releases, but rather to add perl5 as a sort of "metapackage" that is essentially the same as perl5.30. I guess metapackage isn't the right word, either. In reality more like, it's the same package as perl5.30, but simply with a more generic name that maps to whatever specific release has been blessed as the MacPorts default perl. So, these ports would all exist:
> 
> 	• perl5 <= the "metapackage", and is actually the same port as perl5.30, perl5.32, or whatever is deemed to be the current MacPorts default perl.
> 	• perl5.30
> 	• perl5.28
> 	• perl5.26
> 	• ...
> So if a particular port is okay with blindly using a version of perl that tracks with the latest MacPorts default perl, they can use perl5. If a port breaks when the MacPorts default perl gets changed, then the port could still revert back to specifying a specific version of perl, by simply changing the perl5 to perl5.28.

"If a port breaks" goes back to what I said above: either you're spending days testing every module before a major perl update to determine which ones break, or you're planning to rely on users noticing and reporting the breakage. I don't want our users to experience breakage and have to report it, because it is likely that some portion of those users will not report the breakage and will instead equate the broken port with MacPorts itself being broken and abandon MacPorts. I don't want to give users reasons to abandon MacPorts.

I don't think adding a set of ports for "the current version of perl" solves the maintenance problem of having multiple versions of perl.