[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: James McCoy <jamessan_at_jamessan.com>
Date: Tue, 22 Oct 2019 19:07:56 -0400

On Mon, Oct 21, 2019 at 01:35:45PM +0200, Branko Čibej wrote:
> On 21.10.2019 13:16, Julian Foad 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.
> >
> > 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.
>
>
> If you (or some other RM volunteer) is prepared to roll 1.14 with Python
> 3 support in, say, a month after 1.13 -- with all that implies for
> downstream packagers -- then sure.

FWIW, since we switched to the new release model, I (in my capacity as
packager for Debian) basically ignore non-LTS releases. It's easier to
ignore them, since I know I only want an LTS release in Debian's
release, and would rather not risk getting "stuck" with a non-LTS
release when Debian freezes.

The downside to this is that the non-LTS releases don't get any of the
feedback of going through the various builds/tests on Debian's
infrastructure.

I'll likely make an exception for the Python 3 support since there's a
significant push within Debian to switch over to Python 3 ASAP, and
definitely in time for the next release.

Cheers,

-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB
Received on 2019-10-23 04:18:44 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.