How to discontinue ports completely (py26 deprecation) ...
nad at acm.org
Sun Aug 14 21:12:31 PDT 2016
On 2016-08-14 21:52, Fred Wright wrote:
> On Sat, 13 Aug 2016, Christopher Jones wrote:
>>> On 12 Aug 2016, at 11:30 pm, Fred Wright <fw-Wo0XcGa3PpfR7s880joybQ at public.gmane.org> wrote:
>>> On Fri, 12 Aug 2016, Chris Jones wrote:
>> I agree there is no way to migrate completely to 3.x, but I am still not
>> really convinced keeping both the 2.6 and 2.7 versions in MacPorts is
>> worth the effort. 2.6 needs to be dropped sometime...
> Given that the effort involved in keeping it is zero, and the effort
> involved in removing it is nonzero, I don't think the "effort" argument
> really flies.
Unfortunately, it's not true that the effort is zero. The most obvious
example is supporting new OS X / macOS releases. Often there are subtle
change in a release that have unexpected consequences and break old
end-of-life releases, like 2.6 for which upstream support ended years
ago. Another example is changing network and security standards which
can cause old versions running on old OS X releases to break. Python
2.6 (and earlier, as well as older, non-current versions of Python 3.x)
has examples of both of these problems. The last upstream release of
2.6.x will not build or test correctly on current OS X systems. That
means the downstream distributors, like MacPorts, have to investigate,
backport and/or develop new fixes, test them, then test and update them
with newer OS X releases. And that's just for the Python interpreter
and standard library. Similar issues arise with third-party Python
packages that may or may not be supported on older versions by their
upstream developers. Although I'm not a MacPorts developer, from an
upstream point of view I'm fully supportive of dropping 2.6 ports at
this point. I'd rather see the MacPorts project volunteers spend their
precious time on things that will help more people. 2.7.x is a special
case and upstream has committed to fully support it until 2020 and to
keep 2.7.x running on new releases, we still have to do work upstream.
That doesn't mean everybody should have to for retired releases. And,
regardless of other options (like migrating to Python 3.x), I can't
imagine that it would be very difficult to migrate nearly anything that
is still running on Python 2.6.x to 2.7.x. IMHO, it's really not doing
anyone any service to keep 2.6.x and other old releases alive at this stage.
nad at acm.org -- 
More information about the macports-dev