[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: Nathan Hartman <hartman.nathan_at_gmail.com>
Date: Mon, 21 Oct 2019 10:10:48 -0400

On Mon, Oct 21, 2019 at 8:29 AM Julian Foad <julianfoad_at_apache.org> wrote:

> Mark Phippard wrote:
> > Also, as brane already pointed out, this would also be making a mockery
> of regular releases.

I'll throw this wacky idea out there...

(With endless respect for everyone here, always.)

Suppose we backport the contents of 1.13-rc1 to 1.12.3 such that 1.12.3
is identical to 1.13-rc1 except for version numbers. Afterwards, merge
swig-py3 to trunk, backport it to 1.13, issue 1.13-rc2, start a 4-week

This (wacky idea) is meant to accomplish several things:

1. We can get the important changes Julian mentioned released, as

2. If I understand HACKING correctly, we can release 1.12.3 ON TIME --
meaning around the same time that we would have released 1.13, since it
would be a patch release that doesn't require a 4-week soak. Please
correct me if I'm mistaken on this point. And, for all practical
purposes, we did a soak.

3. Packagers who have worked on 1.13-rc1 won't lose the work they've
done -- PROVIDED that we communicate well that we decided to renumber
it as a patch release and that they'll find all contents identical
except for version numbers. I hope Mark will tell us if this would be
an acceptable compromise?

4. We wouldn't "make a mockery" of regular releases, since 1.12.3 would
occur at the regular time, only with a different version number than we
previously thought. Some might balk at that different version number
but I think that's a much better scenario than 1.14 suddenly not being
the next LTS release, since we've been communicating that it would be
LTS for quite some time and it suddenly not being LTS would confuse a
lot of people. No one will be confused by a 1.12.3 that fixes bugs.

5. We can test the heck out of 1.13 with swig-py3 before rolling 1.13-
rc2. Even if we find blocking breakage, we have time to restart the
soak and still get it out there before Python 2 goes EOL.

Justification for all this:

While we have a release schedule (and YES, I do think we should stick
to it!), Python 2 going EOL is an exceptional circumstance; and so, if
this event causes our release schedule to be a bit different, I don't
see that as a negative; rather, I see it as being responsive to a
pretty significant change that is coming and to users who have written
to us with questions and concerns about this change.

Now, like I said:
* I say all of this with endless respect for everyone.
* I'm throwing it out there as a wacky idea.

Received on 2019-10-21 16:11:06 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.