subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@apache.org>
Subject Re: 1.13.x and swig-py3 (was: Re: Test failures with Python 3 (Re: PMCs: any Hackathon requests? (deadline 11 October)))
Date Sat, 19 Oct 2019 18:11:48 GMT
On 19.10.2019 12:06, Johan Corveleyn wrote:
> On Sat, Oct 19, 2019 at 1:23 AM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>> Yasuhito FUTATSUKI wrote on Fri, Oct 18, 2019 at 23:09:19 +0900:
>>> On 2019/10/16 21:12, Johan Corveleyn wrote:
>>>> This makes me wonder: should that be fixed specifically on trunk, and
>>>> nominated for backport to 1.13, so we can possibly claim basic support
>>>> for Python 3 in our build and test processes (in at least one released
>>>> version) before the end of this year?
>>>>
>>>> Or should we reintegrate the swig-py3 branch ASAP, and nominate *that*
>>>> for backport to 1.13, so we can have Python 3 support, including swig
>>>> bindings?
>>> I prefer the latter, as one of users :) I want to use
>>> tools/hook-scripts/mailer/mailer.py with Python 3.
>> If we want this to happen, we should first of all complete the swig-py3 branch
>> and merge it to trunk.
> Yes, and I think the branch is now ready for merge to trunk.
>
>> What's not clear to me is what would happen afterwards.  Is anyone proposing to
>> delay 1.13.0 until swig-py3 is merged (remember that we are already more than
>> halfway through the soak)?  If not, how would merging swig-py3 to 1.13.x
>> coexist with the premise of "no destabilizing changes in patch releases"?
>> Would we have to delay merging swig-py3 to 1.13.x until January, when py2 has
>> finally gone out of support?
> I wouldn't postpone 1.13.0 for it. I suppose the best way is that we
> propose it for backport for 1.13.1, shortly after 1.13.0 has been
> released.
> Also: the swig-py3 branch does not break our support for py2. With
> that branch, both py2 and py3 swig-bindings can be built and run fine.

But it does introduce major changes in the bindings, for Py2 as well.
I'd really, really rather not drop them on unsuspecting users in a patch
release.

By the principle of least surprise, I think it would be better to merge
to trunk, create a new 1.13.0 release candidate and (maybe?) restart the
soak.


>> What should we do about swig-py3 support in 1.12.x and 1.10.x, which are both LTS?
> Only 1.10.x is LTS (and 1.9.x perhaps? But ISTR we eol'ed that). I
> suppose a backport to 1.10.x would be a good idea, so we have at least
> one LTS release this year that supports py3.


-0, for the same reason as above. We'll have the LTS that supports
Python 3 in a few months. Anyone who cares so much about Python 3
support will be able to use 1.13.0 (or .x). And of course ... EOL or
not, Python 2 will be around for a while yet.

>> Should we say anything about swig-py2 / swig-py3 in the release notes _today_,
>> before 1.13.0 has been released, about our plans for 1.13.x patch releases?


Given that I prefer releasing this with 1.13.0, the answer is, of
course, "yes."

-- Brane


Mime
View raw message