#50512: perl5: obsolete subports perl5.16 perl5.18 perl5.20 --------------------------+--------------------- Reporter: devans@… | Owner: mojca@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: perl5 | --------------------------+--------------------- Comment (by mojca@…): It's true that they are no longer needed, but we might get similar requests like a while ago when users were asking for the old perl ports (like perl5.14) to stay. Honestly I don't know what to do. The old ports themselves don't really do any harm nor do they add any significant overhead (like the modules do). -- Ticket URL: <https://trac.macports.org/ticket/50512#comment:1> MacPorts <https://www.macports.org/> Ports system for OS X

#50512: perl5: obsolete subports perl5.16 perl5.18 perl5.20 --------------------------+--------------------- Reporter: devans@… | Owner: mojca@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: perl5 | --------------------------+--------------------- Comment (by devans@…): A slightly more permissive approach would be to follow [http://perldoc.perl.org/perlpolicy.html#MAINTENANCE-AND-SUPPORT the perl developers policy] and obsolete all perl versions that are not supported upstream. As of the release of perl 5.22, perl5.18 and earlier became unsupported. Upon the release of perl5.24 support for perl5.20 will cease and so on. -- Ticket URL: <https://trac.macports.org/ticket/50512#comment:3> MacPorts <https://www.macports.org/> Ports system for OS X

#50512: perl5: obsolete subports perl5.16 perl5.18 perl5.20 --------------------------+--------------------- Reporter: devans@… | Owner: mojca@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: perl5 | --------------------------+--------------------- Comment (by dluke@…): We should obsolete all of them (or at least all of them that aren't supported upstream). End users who really want old perl can pull the old pre-obsolete portfile into a local repo (or could have stepped up to maintain the old port). -- Ticket URL: <https://trac.macports.org/ticket/50512#comment:5> MacPorts <https://www.macports.org/> Ports system for OS X

#50512: perl5: obsolete subports perl5.16 perl5.18 perl5.20 --------------------------+--------------------- Reporter: devans@… | Owner: mojca@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: perl5 | --------------------------+--------------------- Comment (by devans@…): Replying to [comment:5 dluke@…]:

We should obsolete all of them (or at least all of them that aren't supported upstream). End users who really want old perl can pull the old pre-obsolete portfile into a local repo (or could have stepped up to maintain the old port).

Agreed. We've gone to a lot of work to only support one version of perl. At this point, it makes no sense to me to keep perl versions that we, ourselves, don't support in applications or with modules. -- Ticket URL: <https://trac.macports.org/ticket/50512#comment:7> MacPorts <https://www.macports.org/> Ports system for OS X

#50512: perl5: obsolete subports perl5.16 perl5.18 perl5.20 --------------------------+--------------------- Reporter: devans@… | Owner: mojca@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: perl5 | --------------------------+--------------------- Comment (by dluke@…): Not many comments because no one cares about the old perls (for some sets of 'no one'). The reality is that it's really easy to keep cruft like that around because it keeps working and no one complains. However, we do our users a dis-service distributing software that's not maintained upstream. For the very few use-cases where people actually need the old version, they can resurrect the port (and/or someone could run an alternate ports tree with just "old unmaintained crap" for those who really want to have it). -- Ticket URL: <https://trac.macports.org/ticket/50512#comment:9> MacPorts <https://www.macports.org/> Ports system for OS X

#50512: perl5: obsolete subports perl5.16 perl5.18 perl5.20 --------------------------+--------------------- Reporter: devans@… | Owner: mojca@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: perl5 | --------------------------+--------------------- Comment (by pixilla@…): Replying to [comment:9 dluke@…]:

Not many comments because no one cares about the old perls (for some sets of 'no one').

The reality is that it's really easy to keep cruft like that around because it keeps working and no one complains. However, we do our users a dis-service distributing software that's not maintained upstream.

For the very few use-cases where people actually need the old version, they can resurrect the port (and/or someone could run an alternate ports tree with just "old unmaintained crap" for those who really want to have it).

+1 -- Ticket URL: <https://trac.macports.org/ticket/50512#comment:11> MacPorts <https://www.macports.org/> Ports system for OS X

#50512: perl5: obsolete subports perl5.16 perl5.18 perl5.20 --------------------------+--------------------- Reporter: devans@… | Owner: mojca@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: perl5 | --------------------------+--------------------- Comment (by devans@…): Sounds reasonable. However, it may be simplistic to think that one blanket policy would fit all ports. In the perl case, I think these are the issues that might be considered: * is it useful to support outdated versions of perl that are no longer supported upstream by updates or security fixes? * does it make sense to commit scarce maintainer resources to maintaining such outdated software? * does anyone really care? (see comments from lduke, pixilla above) * are these outdated versions useful when we don't support up-to-date modules for them (their functionality is currently limited to those modules that were shipped as core modules without further update)? * if there is a point in time where these ports should be removed, when is that? What's the criteria? * have any of the current perl ports met this criteria (and should be immediately removed)? * at what point in the future might additional ports meet this criteria? (e.g. when new versions are released upstream, etc) * once a policy is established, how can we document this policy and make that documentation readily available to the maintainer community? <soapbox>[[BR]] This last question is one that I consider to an important issue with respect to any MacPorts policy. IMO, there would be much less indecision about what to do in any given case if there was a well documented set of written policies to which a maintainer could refer. Currently, any such policy is more of an oral tradition and varies according to who is telling the story. Many organizations maintain something like a "policy & procedures" manual. Why not MacPorts?[[BR]] <\soapbox> I'll be interested to hear what the meeting attendees thing about these topics. Thanks for organizing the meeting. -- Ticket URL: <https://trac.macports.org/ticket/50512#comment:13> MacPorts <https://www.macports.org/> Ports system for OS X