Hi all, I already wanted to make a similar proposal (at least for py24) so I am in favour of this proposal.
+1 for removing 2.4 and 2.5. I would not remove 2.6 for now. It is still well supported and py26 subports are in general easier to maintain. There is also some value in having around for testing, as some very conservative Linux distributions still support them for years to come. When it comes to Py3, I usually provide only py33 and py34 subports for new. Here I would propose to phase at least py31, but I do not thing py32 is very useful by now neither. ~petr On 16 Sep 2014, at 23:11, Joshua Root <j...@macports.org> wrote: > On 2014-9-17 04:23 , Lawrence Velázquez wrote: >> My problem with python24 and python25 (aside from having to maintain dead >> software) is that they aren't framework installations, making them even more >> of a pain to deal with. Note the 2.4/2.5-specific logic in python-1.0, for >> example. python26 is pretty similar to python27, at least. > > 2.5 is a framework install, it just acts like it isn't in some ways for > backward compatibility (slightly long story). 2.4 is a framework install > on 32-bit systems. > > Certainly you'd be pretty crazy to try using either one for real work on > any Mac from the 64-bit era, unless your work involves being forced to > use legacy code that won't work with 2.6+. (No ctypes, just for starters...) > > - Josh > _______________________________________________ > macports-dev mailing list > macports-dev@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-dev _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev