[ZODB-Dev] RFC: Python2 - Py3k database compatibility

[Jim Fulton]

On Mon, Apr 29, 2013 at 1:15 PM, Tres Seaver <tseaver at palladion.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 04/29/2013 12:44 PM, Jim Fulton wrote:
>> Yes.  There are lots of features I'd like to add to ZODB.  I tend to
>> work on them when I have time (infrequently) or where we have a
>> driving need at ZC.  Long ZODB release cycles provide a lot of stop
>> energy.
>
> We are already developing this way (the 'py3' branch has not been
> merged).  However, if you do a lot of Python2-only feature work and merge
> to master, you will likely push back to horizon for merging that branch:
>  we will have to port any work done to it.

I'd be happy to say that anything pushed to master has to pass tests on
Python 3. I have no interest in delaying Python 3 work.

>
> Using the "4.0" label to signal "big changes ahead, evaluate carefully
> before upgrading" was the primary reason I had been pushing to get the
> Py3k stuff landed

Apparently. :)  But, IIRC, you never discussed this with me.
When I announced 4.0, the big change was splitting off ZEO,
persistent, and later BTrees.  In fact, as you may remember,
I suggested splitting BTrees off in 5, because I didn't want to
to delay 4.

> (the low-risk thing would have been more naturally
> labeled "3.11").

Except I explicitly said that 4.0 was supposed to be
a low risk release. That's why 3.11 was just a meta-release
to aid people in the transition to 4.

When I saw all your activity on porting to Python 3, I
stepped back to give you room.  But now, several months
have gone by and we're more or less where we were in
November wrt 4.0.

I greatly appreciate and support you guys have done on Python 3 porting.

I don't mean to criticize the work you've done.  If anyone deserves
criticism, it's me for not staying on top of this.

We need to get to a point where we can release frequently, with confidence.
That doesn't mean we will; it depends on people's time to contribute.
But we need to be able and we need to plan our activities so we can
release frequently.

Whether 4.0 supports Python 3 or not, let's quickly get to the point where
tests are run and pass on both Python 2 and 3.  Once we get to that point,
we won't accept pull requests that break Python 3 (or 2, of course).
But let's get to the point soon where we can make Python 2 releases
with confidence.

Jim

-- 
Jim Fulton
http://www.linkedin.com/in/jimfulton