[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [offlist] Re: Merging branches/swig-py3 to trunk

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Tue, 12 Nov 2019 11:45:28 +0000

Nathan Hartman wrote on Mon, Nov 11, 2019 at 22:13:54 -0500:
> On Fri, Nov 8, 2019 at 3:13 AM Julian Foad <julianfoad_at_apache.org> wrote:
>
> > Nathan Hartman wrote:
> > > Question: Some Python scripts have not been updated for Python 3.x
> > > yet. Should those be listed in the release notes under "Known Issues"?
> > > Should a bug be filed? Or both?
> >
> > Both: an Issue tracking which ones are known broken or untested, and a
> > pointer to it in the release notes.
> >
>
> Recently, Yasuhito posted a thread titled "List of Python scripts
> importing svn.*" I think those are the scripts that need to be checked
> for Python 3 compatibility? Or is it necessary to check all Python
> scripts?
>
> Is it preferred to create one issue to track this, or to first check
> Python scripts and then create an issue per script that is found to be
> incompatible with Python 3?

Whatever is most convenient for the people doing the work.

For example, we could have an umbrella issue "Review Python scripts for py3
compatibility" and spin off individual issues for scripts that have been
reviewed and found to need work. We could have a wiki page tracking work done
and remaining. We could convert the #! line to «#!/usr/bin/env python3» for
any script that's been reviewed and found to work.

> > > [[[
> > >
> > > Support for Python 3.x:
> > >
> > > Some optional features of Subversion utilize the Python scripting
> > > language.
> > >
> > > Subversion's SWIG Python bindings and automated test suite now support
> > > Python 3.x (and newer).
> > >
> > > Support for Python 2.7 is being phased out:
> > >
> > > As of 1 January 2020, Python 2.7 has reached end of life. This means
> > > that Python 2.7 will no longer receive maintenance releases or
> > > patches, even for security issues. All users are strongly encouraged
> > > to move to Python 3.
> > >
> > > As Subversion 1.14 is a Long Term Support (LTS) release with planned
> > > support into 2024, well beyond end-of-life for Python 2.7, the
> > > Subversion developers cannot commit to supporting and testing with
> > > Python 2.7, or to fixing bugs that affect Python 2.7 only, for the
> > > duration of this support period.
> > >
> > > This means that although Subversion 1.14.0 still technically works
> > > with Python 2.7, any later 1.14.x point release may drop this support
> > > if it becomes too difficult to maintain.
> > >
> > > If you must continue using Python 2.7, our previous Long Term Support
> > > release, Subversion 1.10, is supported until 2022. Python 2.7 support
> > > will not be removed from Subversion 1.10.
> > >
> > > Note that Subversion does not require Python for its basic operation.
> > > If you are not using Subversion's SWIG Python bindings, automated test
> > > suite, or other Python-coded tools that ship with Subversion, this
> > > change does not affect you.
> > >
> > > ]]]
> >
> > Sounds good to me.
> >
> > Maybe add a note that in "3.x" we intend to choose a specific "x", in
> > case we forget to update the text when we choose one?
> >
>
> Can we just pick one now rather than put it off and forget?

We can. We can also commit that text right now, and even add TODO's in it
where needed (the 1.14 notes are still work-in-progress).

> I suggest some sort of "rolling" support for Python, where each 1.14.x
> point release will support all Python 3.x releases that are not EOL at
> the time of that point release.

+1 to not supporting EOL Python versions.

> That is:
>
> * When 1.14.0 is released, Python 3.5 will still have 8 months of
> support. Therefore, we will support Python 3.5 through 3.8.

I'd like to add an escape hatch here, to say that in new minor release we'll
make an effort to support the oldest minor line of Python that Python upstream
supports at that time, but may decide to only support, say, py≥3.6, should we
have a good reason to do so.

> * Then, as a hypothetical example, suppose that 1.14.2 is released in
> 2021. Python 3.5 would be EOL. Therefore, we would NOT support
> Python 3.5 anymore, but would support Python 3.6 through 3.9.

+1: A new patch release should support whichever Python versions the previous
patch release (in the same minor line) did, subject to Python EOL terms.

In a new 1.14.x patch release, will we we support all py3.6.y releases, or just
whichever one is current at the time of rolling the 1.14.x tarballs?

> Thoughts?

> > svn 1.9 Py 2.7 supported, Py 3.x not working
> > svn 1.10 Py 2.7 supported, Py 3.x+ supported for build & test, not
> > working for bindings (?)
> > svn 1.14 Py 2.7 unsupported (working in 1.14.0), Py 3.x supported
> >
> > For 1.10 I am offering an example of the form of summary, not sure what
> > the actual status is.
> >
> > If I did my search correctly, there is nothing about Python 3 in any of
> > the 1.10 through 1.14 release notes. Haven't we got something to say
> > about limited support (for build and test?) in some version before 1.14?
> > All I could find was one py3 build fix (r1819444) merged to 1.10.x.
> >
>
> A table like that would be helpful. Hopefully someone knows what the
> actual status of 1.10 is. I guess it can be tested. Only the latest,
> 1.10.6, should be tested.

On 1.10.x svnserveautocheck doesn't support py3, at least. (There may be
additional issues.)

Cheers,

Daniel
Received on 2019-11-12 12:45:36 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.