Change build/find_python.sh and roll 1.14.0-rc3? (was: Re: py2.7 used by default when py2 and py3 are both available)

[Daniel Shahaf <d....@daniel.shahaf.name>]

[Changing the subject for visibility.]

Branko Čibej wrote on Fri, May 15, 2020 at 22:02:53 +0200:
> On 15.05.2020 20:42, Daniel Shahaf wrote:
> > Branko Čibej wrote on Fri, 15 May 2020 18:14 +00:00:
> >> [...]
> > 
> > The documentation <https://subversion.apache.org/docs/release-notes/1.14#python2>
> > reads:
> >
> >     """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."""
> >

> >> It would make sense to prefer Python3 over Python2 by default if both
> >> are available, but I wouldn't go further than that. The order of
> >> executable names should be [python3, python, python2], IIUC the naming
> >> conventions.
> > Sounds good to me.
> >
> > If we make this change, should we roll an rc3 for it?
> 
> It's a pure build script change, but it's always nice to be able to
> essentially rename the RC to the release (except for svn_version.h
> changes). I don't think we have to restart the soak, though.
> 

IIRC the soak was to end on Wednesday and any change requires at least
a week's extension.

Here's the patch.  I smoke tested it and it passed, but I'm seeing tests
randomly fail even in unpatched trunk so I can't an unqualified +1.

[[[
Index: build/find_python.sh
===================================================================
--- build/find_python.sh	(revision 1877789)
+++ build/find_python.sh	(working copy)
@@ -23,7 +23,7 @@
 # Required version of Python
 VERSION=${1:-0x2070000}
 
-for pypath in "$PYTHON" "$PYTHON2" "$PYTHON3" python python2 python3; do
+for pypath in "$PYTHON3" "$PYTHON" "$PYTHON2" python3 python python2; do
   if [ "x$pypath" != "x" ]; then
     DETECT_PYTHON="import sys;sys.exit((sys.hexversion < $VERSION) and 1 or 0)"
     if "$pypath" -c "$DETECT_PYTHON" >/dev/null 2>/dev/null; then
]]]

> >   Otherwise, if we
> > in fact pull py2.7 support at some point (as the release notes allow us
> > to), we'd find ourselves having to bump a dependency's major version in
> > a patch release.
> 
> True.

Cheers,

Daniel

Re: Change build/find_python.sh and roll 1.14.0-rc3? (was: Re: py2.7 used by default when py2 and py3 are both available)

[Daniel Shahaf <d....@daniel.shahaf.name>]

Branko Čibej wrote on Sat, 16 May 2020 13:46 +0200:
> On 16.05.2020 12:00, Stefan Sperling wrote:
> > On Fri, May 15, 2020 at 09:13:38PM +0000, Daniel Shahaf wrote:  
> >> IIRC the soak was to end on Wednesday and any change requires at least
> >> a week's extension.
> >>
> >> Here's the patch.  I smoke tested it and it passed, but I'm seeing tests
> >> randomly fail even in unpatched trunk so I can't an unqualified +1.  
> > I would prefer if we just nominated this for 1.14.1 as usual.
> >
> > This is something that is very, very easy to work around for packagers.
> > And I don't think we are seeing a lot of people making their own builds
> > from source these days, anyway. And even then, in the worst case they ask
> > for help and it's easy to solve.
> >
> > So I see no reason to fix this for .0, not even with the hypothetical case
> > in mind where we would drop python2 support to a stronger degree than 
> > we already have.
> >
> > If it is deemed very important, we could just document this in release
> > notes under "Known issues" until 1.14.1 comes out.  
> 
> Sure, that makes sense, too. After all, we have a bunch of
> python-releated fixes already on trunk that are easily candidates for .1.

Done in r1877835.  Revisions welcome. ☺

Re: Change build/find_python.sh and roll 1.14.0-rc3? (was: Re: py2.7 used by default when py2 and py3 are both available)

[Branko Čibej <br...@apache.org>]

On 16.05.2020 12:00, Stefan Sperling wrote:
> On Fri, May 15, 2020 at 09:13:38PM +0000, Daniel Shahaf wrote:
>> IIRC the soak was to end on Wednesday and any change requires at least
>> a week's extension.
>>
>> Here's the patch.  I smoke tested it and it passed, but I'm seeing tests
>> randomly fail even in unpatched trunk so I can't an unqualified +1.
> I would prefer if we just nominated this for 1.14.1 as usual.
>
> This is something that is very, very easy to work around for packagers.
> And I don't think we are seeing a lot of people making their own builds
> from source these days, anyway. And even then, in the worst case they ask
> for help and it's easy to solve.
>
> So I see no reason to fix this for .0, not even with the hypothetical case
> in mind where we would drop python2 support to a stronger degree than 
> we already have.
>
> If it is deemed very important, we could just document this in release
> notes under "Known issues" until 1.14.1 comes out.

Sure, that makes sense, too. After all, we have a bunch of
python-releated fixes already on trunk that are easily candidates for .1.

-- Brane

Re: Change build/find_python.sh and roll 1.14.0-rc3? (was: Re: py2.7 used by default when py2 and py3 are both available)

[Stefan Sperling <st...@elego.de>]

On Fri, May 15, 2020 at 09:13:38PM +0000, Daniel Shahaf wrote:
> IIRC the soak was to end on Wednesday and any change requires at least
> a week's extension.
> 
> Here's the patch.  I smoke tested it and it passed, but I'm seeing tests
> randomly fail even in unpatched trunk so I can't an unqualified +1.

I would prefer if we just nominated this for 1.14.1 as usual.

This is something that is very, very easy to work around for packagers.
And I don't think we are seeing a lot of people making their own builds
from source these days, anyway. And even then, in the worst case they ask
for help and it's easy to solve.

So I see no reason to fix this for .0, not even with the hypothetical case
in mind where we would drop python2 support to a stronger degree than 
we already have.

If it is deemed very important, we could just document this in release
notes under "Known issues" until 1.14.1 comes out.