bioperl / bioperl-live

Core BioPerl 1.x code
http://bioperl.org
296 stars 182 forks source link

Minimum Perl version should be set to v5.8 #375

Open zmughal opened 1 year ago

zmughal commented 1 year ago

The current dist has a minimum version of v5.6 (set at t/00-compile.t).

But as discussed in this comment, the minimum version based on the syntax and features used is v5.8.

cjfields commented 1 year ago

@zmughal Does PDL (or the Perl community in general) have a minimum recommended version to support? I'd say go with that for support and testing purposes. Perl 5.8 was the minimum 5+ years ago, this may have changed.

Note this doesn't mean that older versions won't work, just that we will not fix bugs specific for older Perl releases that the Perl community no longer maintains nor supports.

zmughal commented 1 year ago

Depends on where they are in the river of dependencies.

Toolchain code still targets Perl v5.8.1, but that's very high up so not really applicable here.

PDL has a minimum of Perl v5.10 and that was bumped in 2015 to support 64-bit in more places and remove old code.

Other tools promise to work with Perls within the last N years, so N = 10 would be v5.20. A good summary/boilerplate text for this approach is what RJBS uses here to insert support information into documentation.

I did some plotting earlier to find out what Perl modules on CPAN are doing in general:

image

So the next biggest versions are v5.10 and v5.14.

In my opinion, I think v5.10 could be done safely, but to get a real idea, it would be best to see what downstream users are using. Looking at say, Prokka, I see that it only uses v5.6 syntax (which doesn't mean Prokka users are on v5.6, just that no newer features are needed to run it and will work with almost any later Perl).

zmughal commented 1 year ago

Though the existing BioPerl distributions are always on CPAN if any applications need to pin to an older version. Bumping the version is mainly for if new features are needed to write better code (cleaner, faster, more correct, etc.). For example, if one wants to use the new try-catch syntax instead of eval, you need at least v5.14 to use https://metacpan.org/pod/Feature::Compat::Try which makes that available using the XS keyword API introduced in v5.14.

zmughal commented 1 year ago

I ran an analysis of the dependencies last week and only now looked at the output. :wink:

The runtime dependencies have a minimum Perl version of v5.12 via Bio::Root::Test (runtime requires)→ Test::Most (runtime requires)→ Test::Deep https://metacpan.org/release/RJBS/Test-Deep-1.202. While somebody could install an older version of Test::Deep. An older Test::Deep could be used if needed https://metacpan.org/release/RJBS/Test-Deep-1.130.

This doesn't mean the minimum version must be increased, but is just another data point to consider. If testing on a version below that, an older version of Test::Deep would have to be explicitly installed (e.g., inside of the CI workflow).

cjfields commented 1 year ago

Thanks for running that @zmughal. I vote we go with the minimum Perl version from the runtime analyses, Perl 5.12 is just over 13 yrs old (2011). Not that it's necessary, but for a simple comparison: requires Python 3.6 or newer (Python 3.6 was released in 2016).

zmughal commented 1 year ago

Update re: toolchain support:

In the end, we wrote an amendment to the Lancaster consensus, stating that the toolchain would track the perl of 10 years ago. That would mean that this year we’d target v5.18 — but we also said we’d let Red Hat v7 reach end of maintenance support before moving past its version of perl, v5.16.

That means v5.16 this year, v5.20 next, then v5.22.

via https://rjbs.cloud/blog/2023/05/pts-2023-lyon-amendment-2-5/.