perl and python version update

Giuseppe 'ferdy' Miceli ferdy at
Wed Jun 2 11:12:00 UTC 2021


> On 2 Jun 2021, at 09:29, Ken Cunningham <ken.cunningham.webuse at <mailto:ken.cunningham.webuse at>> wrote:
> Seems like a fine idea to me. Thing is, you actually don't want to be that current anyway.

1. as far i understood, for perl the recommended version should be perl5.30 which is stable (even tho’ not maintained), one year old (latest updated 20200601):

	version	latest update	status
	5.30		2020-06-01	old version - not maintained
	5.32		2021-01-23	old version - still maintained
	5.34		2021-05-20	current stable - not yet in macports

moreover it is more “complete” in terms of modules:

	ferdy at wabi:~$ port info --name p5.32* | grep name | wc -l
	ferdy at wabi:~$ port info --name p5.30* | grep name | wc -l
	ferdy at wabi:~$ port info --name p5.28* | grep name | wc -l
	ferdy at wabi:~$ port info --name p5.26* | grep name | wc -l

2. what about python? as far as i understood should be 3.9 (also one year old and with 3.10 still in beta, expected release oct 2021):

	version	maintainance	release		end of support
	3.9		bugfix		2020-10-05	2025-10
	3.8		bugfix		2019-10-14	2024-10
	3.7		security		2018-06-27	2023-06-27
	3.6		security		2016-12-23	2021-12-23
	2.7		end-of-life	2010-07-03	2020-01-01

as for modules, this is the status:

	ferdy at wabi:~$ port info --name py39* | grep name | wc -l
	ferdy at wabi:~$ port info --name py38* | grep name | wc -l
	ferdy at wabi:~$ port info --name py37* | grep name | wc -l
	ferdy at wabi:~$ port info --name py36* | grep name | wc -l
	ferdy at wabi:~$ port info --name py27* | grep name | wc -l

does it make sense? also, what are we supposed to do with python2.7? 

> On Tuesday, June 1, 2021, Daniel J. Luke <dluke at <mailto:dluke at>> wrote:
> On Jun 1, 2021, at 4:25 PM, Ken Cunningham <ken.cunningham.webuse at <mailto:ken.cunningham.webuse at>> wrote:
> >> is there any overall strategy regarding the update of perl and python version as dependencies?
> >> 
> > The basic idea was to be rational about things, so that end-users don’t need many different perls and pythons installed just because, for example, someone noticed a new perl came out last Tuesday and so changed their ports to that.
> > 
> > The admins would set the “recommended” perl and python based on updates and software conformance, and all ports would try to use that (unless some given version would be the only version that would work).
> > 
> > And then, en-masse, at the right moment the “recommended” version would change, all the ports would more-or-less move to the new default at once, if we could.
> > 
> > How well this is working, whether it is working at all, and how well it is or is not generally supported by the group I could not say.
> > 
> > But it seemed like a good idea, when for example one needed to build and install two or three perls and two or three pythons just to install git.
> For perl, we should just ship one perl as 'perl5' and have everything depend on it (and revbump the world of perl when we upgrade it). It takes us too long to migrate everything 'nicely'
> I suspect we could do this for python as well, but I've not looked recently at how disruptive newer python versions are.
> ... but I've said it before and people don't really like that idea, I guess :)
> -- 
> Daniel J. Luke

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the macports-dev mailing list