ciao,
> On 2 Jun 2021, at 09:29, Ken Cunningham <ken.cunningham.web...@gmail.com
> <mailto:ken.cunningham.web...@gmail.com>> 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@wabi:~$ port info --name p5.32* | grep name | wc -l
15
ferdy@wabi:~$ port info --name p5.30* | grep name | wc -l
1850
ferdy@wabi:~$ port info --name p5.28* | grep name | wc -l
1848
ferdy@wabi:~$ port info --name p5.26* | grep name | wc -l
1847
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@wabi:~$ port info --name py39* | grep name | wc -l
1036
ferdy@wabi:~$ port info --name py38* | grep name | wc -l
1278
ferdy@wabi:~$ port info --name py37* | grep name | wc -l
1299
ferdy@wabi:~$ port info --name py36* | grep name | wc -l
1060
ferdy@wabi:~$ port info --name py27* | grep name | wc -l
1331
does it make sense? also, what are we supposed to do with python2.7?
—
ferdy
> On Tuesday, June 1, 2021, Daniel J. Luke <dl...@geeklair.net
> <mailto:dl...@geeklair.net>> wrote:
> On Jun 1, 2021, at 4:25 PM, Ken Cunningham <ken.cunningham.web...@gmail.com
> <mailto:ken.cunningham.web...@gmail.com>> 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
>
