[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: Stefan Sperling <stsp_at_elego.de>
Date: Tue, 22 Oct 2019 18:59:50 +0200

On Tue, Oct 22, 2019 at 10:13:04AM -0400, Mark Phippard wrote:
> I do not think the current 1.13 release is worth releasing. I think we
> should merge the Py 3 branch and release that as 1.13 once we think it is
> ready. That should essentially become the release we maintain until there
> is something new worth generating a new minor release, whenever that may be.

Since the process for 1.13 has already started, why don't we finish the
release as planned? And discuss release policy changes for 1.14, which
is happening in only 6 months from now?
That would give us plenty of time to conclude this discussion without
rushing through it. And 1.14 is supposed to be the next LTS anyway.

I could be wrong but it seems like we're having this discussion only because
new work on python 3 and the new release cycle happened to overlap, and
otherwise we would not be having it?
If getting the python 3 changes out quickly is important, could we merge
some or all python 3 fixes into 1.13.1, or are they all breaking API?
I haven't had time to actually look at the patches and this entire thread,
so please excuse me if this has already been discussed and ruled out.

I also agree with Julian that it will take time to see results from our
release policy changes. We are still at the stage where we are learning
a new process and can fine-tune it based on new experience and insights.
As long as Julian is willing to keep up his role as a time-based release
manager, I believe we should keep trying. If we reach a point where there
is nothing at all to release after 6 months, we can still reconsider.

It would be interesting to learn what our new developers think about this.
I am sure that getting their changes released is important to them.
Time-based releases provide a certain amount of anticipation and clarity when
a release is supposed to happen. In the past, we used to discuss what to
release and when, every single time, and often delayed releases for months.
That could put new contributors off because they might not feel like they
have a huge standing when arguing for their changes to be released soon.
While the results of their work are sitting on trunk which nobody is actually
running in production. That certainly would not motivate me, if I try to put
myself in their shoes.
Received on 2019-10-22 19:00:10 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.