On 2010/07/02 14:49, David Coppa wrote: > On Fri, Jul 2, 2010 at 2:42 PM, Damien Miller <[email protected]> wrote: > > On Fri, 2 Jul 2010, Pekka Niiranen wrote: > > > >> Damien Miller wrote: > >> > On Wed, 30 Jun 2010, Stuart Henderson wrote: > >> > > >> > > The things I use regularly work fine. Admittedly this is not all that > >> > > many programs, but in the absence of better reports from the people who > >> > > actually requested the update... > >> > > > >> > > No additional regression test failures on amd64 (one is fixed). > >> > > > >> > > I am ok with the update and switching MODPY_VERSION. > >> > > >> > ok djm@ too, I have been running with 2.6 as the default for > 1 year. > >> > > >> The last 2.x version of Python, v2.7, is about to be released on July. > >> Do not switch to v2.6, please.. > > > > Care to give a reason why not? Typically 2.x.0 releases have suffered > > from a number of bugs and compatibility problems. I don't think it is > > a great idea that we jump onto them straight away, and we certainly > > haven't done so in the past. > > You may have reasons, but these sentences from > http://docs.python.org/dev/whatsnew/2.7.html sound good to me: > > <<Python 2.7 is planned to be the last of the 2.x releases, so we > worked on making it a good release for the long term.>> > > <<This means that 2.7 will remain in place for a long time, running > production systems that have not been ported to Python 3.x.>> > > <<It?s very likely the 2.7 release will have a longer period of > maintenance compared to earlier 2.x versions. Python 2.7 will continue > to be maintained while the transition to 3.x continues, and the > developers are planning to support Python 2.7 with bug-fix releases > beyond the typical two years.>>
This particular diff is recent but we have been preparing for the move to Python 2.6 for quite some time already. It has already been through bulk builds some months ago and many other ports fixed (e.g. those looking only for python 2.5 and older). This will all need to be revisited for 2.7 as I am pretty certain there are things which need fixing. Doing this will push us way beyond a safe margin for fixing any remaining discovered runtime problems in time for OpenBSD 4.8.
