duplicity-team team mailing list archive

[Michael Terry <mike@xxxxxxxxxxx>]

It's been 10 months since we last talked Python 3, and you all know how
much I love talking about it.  So I  have another Python 3 proposal.

The last plan-of-record was to keep 2.4 support and use 2to3 to generate a
python3-compatible version of the source on the fly.  Which is a bit of an
all-or-nothing conversion.

I made such a branch, and sent an email to duplicity-talk asking for
testers, but no one bit.  And because it's an all-or-nothing approach, the
diff got a bit large (2to3 can't handle some of the trickier aspects like
unicode handling, so there needed to be a string abstraction layer).

So, I'm now revisiting the other idea we had, of requiring python2.6 and
bumping the version to 0.7.  We'd keep the 0.6 line open for critical bugs
only (I'd personally suggest defining critical as "data loss").

This way, we can slowly introduce __future__ imports to the code base and
eventually the 0.7.x line would work in python3 as well as python2.  But it
would be a gradual thing, easier to test and easier to review.

There are clearly still invested RHEL5 users, as my recent quick poll on
the mailing list showed.  But I doubt RHEL5 users are looking for new
features.  They've been on RHEL5 for six years, they probably value
stability most and have their backup routine locked in already.  I think a
critical-only 0.6 maintenance lifetime would serve them well.

Ideally, we'd see a release of 0.6.23 before switching, since it has a data
loss fix in it already.

Thoughts?

-mt