Python 3

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> Honestly, there's no downside to saying that release X is going to
> require Python 2.6; people who depend on an older version of python
> just don't upgrade their installation of bazaar. Anyone sufficiently
> motivated can backport code to the legacy branch (say, to accommodate
> a new wire protocol), upgrade python without official distribution
> support (you *can* compile python on a RHEL box when you need a newer
> version!), or petition for a compatibility mode (please provide a bzr
> 2.2 server on legacy.launchpad.net, here's a bundle of money...)
> 
> Frankly, things like native NTLM support can't be integrated cleanly
> while you support Python 2.4 (you need the MD4 support in the newer
> hashlib module for the pure python implementation). As it is, last
> time I checked Bazaar 1.6 was the only version available in any RHEL5
> repository, so I'm not sure waiting for RHEL6 is really going to make
> a difference.

Toshio maintains an rpm for RHEL of bzr. So while it isn't in the
official repo, it is still trivially available.

I've often felt that "if you can upgrade bzr, you can upgrade python",
but apparently that feeling is not held. (One is considered a user-space
command, the other a system-wide infrastructure.)

My personal feeling is that we can do something like:

1) 2.2 will be python2.4 compatible
2) 2.3 will drop 2.4 (maybe 2.5) support.
3) We continue with our current methodology of supporting old releases
(2.0/2.1/soon to be 2.2) for some time. I don't know whether we'll drop
2.0 as a supported stable series now that 2.2 will be released.
Regardless, though, we'll certainly still support 2.1, and *that* will
stay 2.4 compatible.

The big concern with having a break at 2.3 is how difficult it will be
to do the fixes in the 2.1/2.2 branch, and have them still apply to the
2.3 branch.

At the moment, most code is not very diverged, so it isn't very hard.
I'm guessing that will mostly stay true. Martin has mentioned that he
likes "except Exception as e" syntax, so there will be some effort
there. If we start using a lot of context objects, that would also make
the code a fair bit different.

> 
> So are we reluctant to drop Python 2.4/2.5 support because we have no
> guarantee of backwards compatibility in the wire protocol and/or
> branch format?  I don't really see us dropping 2a support just because
> we make a move to Python 2.6. Or would we lose major contributors who
> are unable to upgrade their version of Python?

I think it is mostly that we are likely to introduce new RPCs where we
find edge cases that can perform better. Those won't be backported to
older releases (because it is not a bugfix/security fix).

That said, we are unlikely (though it has happened) to remove RPCs. In
which case older clients talking to newer servers will work like they
always have. And newer clients talking to older servers will know to
fall back to the older code path.

We've had some stress points there, and haven't always gotten it 100%
correct, but generally I think we've done ok.

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwj2sQACgkQJdeBCYSNAAPOSACgrQxwQHGk+aELcJA1A8EaA4Xv
C5EAnit56NyCuw8fxGgiMK+ISM5mLk9M
=Yv53
-----END PGP SIGNATURE-----