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

Re: 1.13.x and swig-py3

From: Mark Phippard <markphip_at_gmail.com>
Date: Mon, 21 Oct 2019 07:43:40 -0400

> On Oct 21, 2019, at 7:16 AM, Julian Foad <julianfoad_at_apache.org> wrote:
>
> Johan Corveleyn wrote:
>> Nathan Hartman wrote:
>> Branko Čibej wrote:
>> > By the principle of least surprise, I think it
>> > would be better to merge to trunk, create a
>> > new 1.13.0 release candidate
>> +1
>> > and (maybe?) restart the soak.
>> I support this idea even if the soak must restart or be extended.
>> +1. Since 1.13 contains so very little, I think it's good to be a bit flexible with our planned timing here, to get this on board. I.e. let's merge it in, cut a new rc, and restart the soak.
>
> Dear all, with respect,
>
> I would love to see the Py3 support released ASAP.
>
> But, have we not learned from our past mistakes? We have prepared a regular release that is right now looking to be ready to deploy next week, on time. If we postpone and destabilize it now [1], this would make mockery of "regular" releases. I would love to trust that merging the branch will go smoothly with no follow-up required and no extra time taken, but history has taught us that it is foolish to assume so.

I think it is just another example that "regular" releases are not appropriate for this project at this stage of its life with a lack of regular activity.

> Surely the right approach is to release what we have got (the currently soaking 1.13), then release the new one as soon as we can get it ready. It sounds like it's not suitable for a patch release, so we'll make it a new minor release, calling it 1.14.

Would this be the LTS release it is supposed to be? Also, as brane already pointed out, this would also be making a mockery of regular releases.

Mark
Received on 2019-10-21 13:43:47 CEST

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.