Merging branches/swig-py3 to trunk

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Merging branches/swig-py3 to trunk

Branko Čibej
Hi everyone,

The support for Swig bindings for Python 3 (on branches/swig-py3) seems
to be complete. Or at least complete enough that any changes that might
still be needed can be done on trunk. I /think/ that includes
documenting the required Swig version (>= 3.0.9, < 4.0, IIUC).

In light of the conversation about 1.13 and Python 3 support, I propose
that:

 1. we release 1.13.0 as planned next week when the soak period ends
    (pending any last-minute critical bugs found, of course);

 2. immediately after the 1.13.0 release, we merge the swig-py3 branch
    to trunk; and,

 3. proceed with 1.14.0 as planned.


*If* we find there's lots of user demand for Python 3 support, we can
always release 1.14.0 early as a regular release, and make 1.15,
released in April, the next LTS.


Given the planned EOL of Python 2, I will, in the following weeks,
change the (macOS) build slaves I control to build with Python 3 by
default, leaving just the one trunk (and possibly one LTS) build to
exercise Python 2 for the build scripts and bindings. I'm also planning
to add an arm32/Raspbian build slave, but got pre-empted by $dayjob, so
that will have to wait a while.


Last but by no means least, I'd like to thank everyone who helped make
this rather important feature work:

$ svn info --show-item=relative-url
^/subversion/branches/swig-py3
$ svn log --stop-on-copy | egrep '^r\d+ \|' | cut -d '|' -f 2 | sort -u
 cmpilato
 danielsh
 futatuki
 luke1410
 troycurtisjr



-- Brane

Reply | Threaded
Open this post in threaded view
|

Re: Merging branches/swig-py3 to trunk

Julian Foad-5
Branko Čibej wrote:
> [...] I propose that:
>
>   1. we release 1.13.0 as planned next week when the soak period ends
>      (pending any last-minute critical bugs found, of course);
>
>   2. immediately after the 1.13.0 release, we merge the swig-py3 branch
>      to trunk; and,
>
>   3. proceed with 1.14.0 as planned.

+1.  Thanks for proposing a specific plan.

> *If* we find there's lots of user demand for Python 3 support, we can
> always release 1.14.0 early as a regular release, [...]

Yes, we can still consider something like that as an option.

> Given the planned EOL of Python 2, I will, in the following weeks,
> change the (macOS) build slaves I control to build with Python 3 [...]

Excellent.  Thanks.

> Last but by no means least, I'd like to thank everyone who helped make
> this rather important feature work:
>
> $ svn info --show-item=relative-url
> ^/subversion/branches/swig-py3
> $ svn log --stop-on-copy | egrep '^r\d+ \|' | cut -d '|' -f 2 | sort -u
>   cmpilato
>   danielsh
>   futatuki
>   luke1410
>   troycurtisjr

Indeed.  Seconded.

- Julian
Reply | Threaded
Open this post in threaded view
|

Re: Merging branches/swig-py3 to trunk

Daniel Shahaf-2
Julian Foad wrote on Wed, 23 Oct 2019 13:23 +00:00:
> Branko Čibej wrote:
> > $ svn info --show-item=relative-url
> > ^/subversion/branches/swig-py3
> > $ svn log --stop-on-copy | egrep '^r\d+ \|' | cut -d '|' -f 2 | sort -u
> >   cmpilato
> >   danielsh
> >   futatuki
> >   luke1410
> >   troycurtisjr

Let's not forget the contribulyzer syntax:

% svn log --stop-on-copy | grep 'by:'
Patch by: Jun Omae <jun66j5 at gmail.com>
%

Reply | Threaded
Open this post in threaded view
|

Re: Merging branches/swig-py3 to trunk

Daniel Shahaf-2
In reply to this post by Branko Čibej
Branko Čibej wrote on Tue, 22 Oct 2019 19:39 +00:00:
>  1. we release 1.13.0 as planned next week when the soak period ends
>     (pending any last-minute critical bugs found, of course);

Speaking of which, do we have time to get the changes currently in
STATUS into .0, or will they need to wait for 1.13.1?  It's two trivial
py3 compatibility patches in the test suite, fewer than 10 lines
changed between them.
Reply | Threaded
Open this post in threaded view
|

Re: Merging branches/swig-py3 to trunk

Julian Foad-5
Daniel Shahaf wrote:
> Branko Čibej wrote on Tue, 22 Oct 2019 19:39 +00:00:
>>   1. we release 1.13.0 as planned next week when the soak period ends
>>      (pending any last-minute critical bugs found, of course);
>
> Speaking of which, do we have time to get the changes currently in
> STATUS into .0, or will they need to wait for 1.13.1?  It's two trivial
> py3 compatibility patches in the test suite, fewer than 10 lines
> changed between them.

Approved and merged, but too late for 1.13.0; they will go in 1.13.1.

("The final week of the stabilization period is reserved for critical
bugfixes; fixes for minor bugs should be deferred to the A.B.1 release."
http://subversion.apache.org/docs/community-guide/releasing.html#release-stabilization-overview 
)

- Julian
Reply | Threaded
Open this post in threaded view
|

Re: Merging branches/swig-py3 to trunk

Daniel Shahaf-2
In reply to this post by Branko Čibej
Branko Čibej wrote on Tue, Oct 22, 2019 at 21:39:23 +0200:
>  1. we release 1.13.0 as planned next week when the soak period ends
>     (pending any last-minute critical bugs found, of course);
>
>  2. immediately after the 1.13.0 release, we merge the swig-py3 branch
>     to trunk; and,

Anyone wants to do the honours?  (Do the merge, or write the 1.14 release notes
for it, or both)?
Reply | Threaded
Open this post in threaded view
|

Re: Merging branches/swig-py3 to trunk

Branko Čibej
On 04.11.2019 05:52, Daniel Shahaf wrote:
> Branko Čibej wrote on Tue, Oct 22, 2019 at 21:39:23 +0200:
>>  1. we release 1.13.0 as planned next week when the soak period ends
>>     (pending any last-minute critical bugs found, of course);
>>
>>  2. immediately after the 1.13.0 release, we merge the swig-py3 branch
>>     to trunk; and,
> Anyone wants to do the honours?  (Do the merge, or write the 1.14 release notes
> for it, or both)?

Merged to trunk in r1869354. I'll let someone else handle the release
notes. :)

-- Brane

Reply | Threaded
Open this post in threaded view
|

Re: Merging branches/swig-py3 to trunk

Julian Foad-5
Branko Čibej wrote:
> Merged to trunk in r1869354.

Thanks!

> I'll let someone else handle the release notes. :)

I'll put up a skeleton 1.14 release notes file today, ready for someone
to fill in a section about Py3.

- Julian

Reply | Threaded
Open this post in threaded view
|

Re: Merging branches/swig-py3 to trunk

Julian Foad-5
Julian Foad wrote:
> I'll put up a skeleton 1.14 release notes file today, ready for someone
> to fill in a section about Py3.

r1869363.

Who can write a note in there about the changes?

- Julian
Reply | Threaded
Open this post in threaded view
|

Re: Merging branches/swig-py3 to trunk

Nathan Hartman
On Mon, Nov 4, 2019 at 6:50 AM Julian Foad <[hidden email]> wrote:
Julian Foad wrote:
> I'll put up a skeleton 1.14 release notes file today, ready for someone
> to fill in a section about Py3.

r1869363.

Who can write a note in there about the changes?

I'm guessing something along these lines... but as you'll see I'm making some assumptions in areas where we haven't yet reached a consensus, so please speak up if you disagree with something!!!

Support for Python 3.x:

Python 3.x and newer are now supported by Subversion's swig-py bindings and automated test suite. Python 2.7 is still supported.

Support for Python 2.7 to be 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. All users are encouraged to move to Python 3.

Subversion 1.14 continues to support Python 2.7 to ease the transition to Python 3 for those who have not yet made the jump. As Subversion 1.14 is a Long Term Support (LTS) release, this gives system operators four additional years of Subversion support for Python 2.7. Note, however, that Subversion 1.15 and beyond will gradually phase out support for Python 2.7.



Reply | Threaded
Open this post in threaded view
|

Re: Merging branches/swig-py3 to trunk

Daniel Shahaf-2
Nathan Hartman wrote on Tue, 05 Nov 2019 04:48 +00:00:

> Support for Python 3.x:
>
> Python 3.x and newer are now supported by Subversion's swig-py bindings
> and automated test suite. Python 2.7 is still supported.
>
> Support for Python 2.7 to be 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. All users
> are encouraged to move to Python 3.
>

Neither maintenance releases nor even security patches.

> Subversion 1.14 continues to support Python 2.7 to ease the transition
> to Python 3 for those who have not yet made the jump. As Subversion
> 1.14 is a Long Term Support (LTS) release, this gives system operators
> four additional years of Subversion support for Python 2.7. Note,
> however, that Subversion 1.15 and beyond will gradually phase out
> support for Python 2.7.

I'm not comfortable with committing to supporting Python 2.7 for the
lifetime of the 1.14 branch — which basically means until the next LTS,
whenever that _actually_ is — when that Python version has been EOL'd
upstream.

I'd prefer to state that Python 2.7 works (as a point of fact), but
support therefor might be dropped at any time, even in a 1.14.x patch
release, at our discretion; and we don't promise to fix bugs that affect
Python 2.7 only.  Of course, we'd not drop support without a good
reason, but I'd like us to have the option to do that.

After all, if a security vulnerability is found in Python 2 in 2020, it
might be impractical for us to even _find_ a Python 2 interpreter to
build and test with.
Reply | Threaded
Open this post in threaded view
|

Re: Merging branches/swig-py3 to trunk

Nathan Hartman
On Tue, Nov 5, 2019 at 1:30 AM Daniel Shahaf <[hidden email]> wrote:
Nathan Hartman wrote on Tue, 05 Nov 2019 04:48 +00:00:
> Subversion 1.14 continues to support Python 2.7 to ease the transition
> to Python 3 for those who have not yet made the jump. As Subversion
> 1.14 is a Long Term Support (LTS) release, this gives system operators
> four additional years of Subversion support for Python 2.7. Note,
> however, that Subversion 1.15 and beyond will gradually phase out
> support for Python 2.7.

I'm not comfortable with committing to supporting Python 2.7 for the
lifetime of the 1.14 branch — which basically means until the next LTS,
whenever that _actually_ is — when that Python version has been EOL'd
upstream.

I'd prefer to state that Python 2.7 works (as a point of fact), but
support therefor might be dropped at any time, even in a 1.14.x patch
release, at our discretion; and we don't promise to fix bugs that affect
Python 2.7 only.  Of course, we'd not drop support without a good
reason, but I'd like us to have the option to do that.

After all, if a security vulnerability is found in Python 2 in 2020, it
might be impractical for us to even _find_ a Python 2 interpreter to
build and test with.

I feel uncomfortable with that, too.

I wrote this to dev@ two months ago, on September 2:

> Py2 is EOL 1/1/2020. Keeping it in 1.14 which implies support until
> 2024 would be a mistake because support will only get harder.
> Imagine what happens when your OS vendor removes Py2 packages. Even
> if Py2 still technically "works" with 1.14 (because that makes it
> easier to support Py3 for the remainder of 1.10), I suggest to
> document that Py2 is explicitly NOT supported in the 1.14 release
> notes. The internal policy should be that once 1.10 support ends,
> changes are allowed to break Py2 support and/or not be tested with
> Py2.

But based on later discussions here, several people expressed concern
about dropping Python 2 support. For example, Mark Phippard spoke of
supporting RHEL 7. Debian still ships with Python 2.7.

I don't think a consensus was ever reached on which version(s) of
Python we actually intend to support in 1.14-LTS and what is the best
path forward for those still using Python 2.7.

Correct me if I'm wrong but I'm guessing that for downstream's
support/planning purposes, if Python 2.7 could be dropped at any
1.14.x point release, isn't that basically equivalent to saying that
Python 2.7 isn't supported at all on 1.14? Because it means that an
update could break things at any time.

I'd be perfectly happy to write something like this in the release
notes:

[[[

Support for Python 3.x:

Subversion's swig-py 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 until 2024, well beyond end-of-life for Python 2.7, the
Subversion developers cannot commit to supporting and testing with
Python 2.7 for the duration of this release, or to fix bugs that
affect Python 2.7 only.

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.

If you do not use the swig-py bindings, automated test suite, or other
Python-coded tools that ship with Subversion, this change does not
affect you.

]]]

But I get the feeling there will be objections.

Bottom line: We need to reach some sort of consensus on this issue.
I've stated my opinion, but I'll be happy to go with whatever this
community decides makes the most sense.

Nathan
 
Reply | Threaded
Open this post in threaded view
|

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

Nathan Hartman
Since you wrote "Any other opinions?" I assume you intended to send
this to the list... (My reply follows below.)

On Thu, Nov 7, 2019 at 5:31 AM Daniel Shahaf <[hidden email]> wrote:
Nathan Hartman wrote on Tue, Nov 05, 2019 at 10:59:32 -0500:
> Correct me if I'm wrong but I'm guessing that for downstream's
> support/planning purposes, if Python 2.7 could be dropped at any
> 1.14.x point release, isn't that basically equivalent to saying that
> Python 2.7 isn't supported at all on 1.14? Because it means that an
> update could break things at any time.

Yes.

> I'd be perfectly happy to write something like this in the release
> notes:
>
> [[[
>
> Support for Python 3.x:
>
> Subversion's swig-py 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 until 2024, well beyond end-of-life for Python 2.7, the
> Subversion developers cannot commit to supporting and testing with
> Python 2.7 for the duration of this release, or to fix bugs that
> affect Python 2.7 only.
>
> 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.
>
> If you do not use the swig-py bindings, automated test suite, or other
> Python-coded tools that ship with Subversion, this change does not
> affect you.
>
> ]]]

Sounds good to me, modulo language changes (s/to fix/to fixing/ and
s/swig-py/SWIG Python/).  Supporting py2 in 1.10 until 2022 is probably
possible, at least for those of us who use LTS distros that will still
be maintaining py2.7 then.

Any other opinions?

> But I get the feeling there will be objections.
>
> Bottom line: We need to reach some sort of consensus on this issue.
> I've stated my opinion, but I'll be happy to go with whatever this
> community decides makes the most sense.

Cheers,

Daniel


Thank you for those corrections.

In addition, I've tweaked it some more and I added a sentence at the
beginning to "introduce" Python, to avoid assuming knowledge.

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?

The updated text:

[[[

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.

]]]

All thoughts / observations / criticisms welcome...

Kind regards,
Nathan
 
Reply | Threaded
Open this post in threaded view
|

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

Julian Foad-5
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.

> The updated text:
>
> [[[
>
> 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?

I think it would be useful to have the info also available in summary
form, a small table.  We might want to put the summary in various
places, not just in the release notes but in maybe another web page
and/or emails etc.  Something like:

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.

- Julian

Reply | Threaded
Open this post in threaded view
|

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

Daniel Shahaf-2
Julian Foad wrote on Fri, Nov 08, 2019 at 08:13:20 +0000:
> 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.

Are you looking for this? —

https://subversion.apache.org/docs/release-notes/1.9#python-2.7

It's interesting to notice that in that paragraph, we dropped support for py2.5
several years after it had gone EOL; and I remember that we added that
paragraph, not as a "planning ahead" thing well ahead of creating the 1.9.x
branch, but as a last-minute addition, shortly before the 1.9.0 final release.
That, and our failure to add support for Python 3 well ahead of py2's EOL, begs
the question of what _other_ dependencies of us are (or will soon be) EOL.

Cheers,

Daniel
Reply | Threaded
Open this post in threaded view
|

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

Daniel Shahaf-2
In reply to this post by Nathan Hartman
Nathan Hartman wrote on Fri, Nov 08, 2019 at 01:39:46 -0500:
> Since you wrote "Any other opinions?" I assume you intended to send
> this to the list... (My reply follows below.)

Yes, that's correct.  I'd intended to reply offlist but changed my mind partway
through drafting and neglected to change the headers back.  Thanks for bringing
the discussion back to the list.

Cheers,

Daniel
Reply | Threaded
Open this post in threaded view
|

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

Nathan Hartman
In reply to this post by Julian Foad-5
On Fri, Nov 8, 2019 at 3:13 AM Julian Foad <[hidden email]> 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?

More below:

> The updated text:
>
> [[[
>
> 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?

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.

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.

* 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.

Thoughts?

For reference, the Python support period graphic you linked before is

More below...

I think it would be useful to have the info also available in summary
form, a small table.  We might want to put the summary in various
places, not just in the release notes but in maybe another web page
and/or emails etc.  Something like:

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.

Cheers,
Nathan

Reply | Threaded
Open this post in threaded view
|

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

Daniel Shahaf-2
Nathan Hartman wrote on Mon, Nov 11, 2019 at 22:13:54 -0500:

> On Fri, Nov 8, 2019 at 3:13 AM Julian Foad <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Merging branches/swig-py3 to trunk

Julian Foad-5
A thought about supporting older Python versions... Somewhere in the
pipeline between community inputs and project outputs, should we
distinguish between "we will not support ..." and "we will be glad to
accept contributions that enable supporting ..."?  How would this look?

I am just getting the feeling that we, a small group of developers, are
trying to make a decision by ourselves when perhaps we should be more
actively reaching out to the wider community to invite them to influence
the result.  I know we have to decide to write something, but maybe we
can write something that encourages the users (yes, the tiny proportion
that might do something about it) to feel they can have a stake in it if
they want to.

- Julian
Reply | Threaded
Open this post in threaded view
|

Re: Merging branches/swig-py3 to trunk

Daniel Shahaf-2
Julian Foad wrote on Tue, 12 Nov 2019 11:59 +00:00:
> A thought about supporting older Python versions... Somewhere in the
> pipeline between community inputs and project outputs, should we
> distinguish between "we will not support ..." and "we will be glad to
> accept contributions that enable supporting ..."?  How would this look?

We could say that Python >=3.5 are "tier 1" supported and Python <=3.4
are "tier 2" supported, in the sense that, for example, a bug that
affects Python <=3.4 only will not be considered a release blocker, but
patches for py<=3.4 will still be accepted, to facilitate developing svn
1.14.x on LTS distros that still package py3.4.  [Here, 3.5 is the
oldest non-EOL Python minor line.]

> I am just getting the feeling that we, a small group of developers, are
> trying to make a decision by ourselves when perhaps we should be more
> actively reaching out to the wider community to invite them to influence
> the result.  I know we have to decide to write something, but maybe we
> can write something that encourages the users (yes, the tiny proportion
> that might do something about it) to feel they can have a stake in it if
> they want to.
>
> - Julian
>
12