duplicity-team team mailing list archive

[Kenneth Loafman <kenneth@xxxxxxxxxxx>]

Hi,

No, I agree.  I was trying to say that we should either
    1) have 0.8 in py2 and py3 branches, e.g. 0.8-py2, 0.8-py3
    2) use 2to3 in single 0.8 branch to produce py3 at install time.
I'm guessing here, but the most stable would be two branches.  I don't have
enough experience with 2to3 to know if it's a viable use case.  I may be
way off base.

0.9-series would be py3 only.

...Ken


On Sun, Dec 17, 2017 at 5:04 PM, Aaron <lists@xxxxxxxxxxxxxxxxxx> wrote:

> Hello all,
>
> On 16/12/17 15:58, Kenneth Loafman wrote:
>
>> I'm sure that we will not want to maintain 2 and 3 versions of the code,
>> so I'm proposing that we cut off 2.x after the 0.8-series and make
>> 0.9-series be 3.x and above.  Now, since I've been reading, where do we
>> start in the 3.x Python series? It seems that there's a break in there,
>> around 3.3 (?) where it would be difficult to maintain backwards
>> compatibility.  I need some advice on this.  Is there need of supporting
>> Python 3.0 thru 3.3?
>>
>
> So are you proposing that we get to full Python 2/3 support in duplicity
> 0.8 and then cut off the Python 2 support? Or do you mean Python 2 only for
> 0.8 and Python 3 only for 0.9?
>
> When we last discussed this:
> https://lists.launchpad.net/duplicity-team/msg04087.html
> https://lists.nongnu.org/archive/html/duplicity-talk/2017-01/msg00052.html
> I think the consensus was that we should support both for one series
> before going solely Python 3.
>
> I am a big fan of ditching Python 2 asap, but do not have a strong view on
> the process. Whatever the plan, we have a lot of basic work (making strings
> clearly unicode/bytes, marking string literals, fixing remaining 2to3
> exceptions etc) to do on the Python 2 code base that will help us get to
> Python 3. One of the big risks is that we get stuck with an incomplete
> Python 3 branch separate to a working Python 2 version, so an advantage of
> the 2/3 approach for a series would be that we could at least push the
> Python 3 work into trunk and avoid it getting out of sync.
>
> Regarding version, I think Python 3.4 is a sensible minimum version for
> now, but I think we bump that to 3.5 in April 2019 (when Ubuntu Trusty
> 14.04 is EOL and all supported Ubuntu versions are running Python 3.5+). I
> would be tempted to take an even more aggressive position (e.g. only
> supporting the latest Python 3 version) if we ever start distributing
> packages that bundle the requirements (e.g. Snap packages or Flatpak) -- as
> I understand it, the main reason to support old versions is to let people
> retrofit a new, non-system version of duplicity on an old OS, which those
> package formats enable. I find it really frustrating not being able to use
> a new language feature because of legacy Python support.
>
> Just my thoughts.
>
> Kind regards,
>
> Aaron
>