[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: Julian Foad <julianfoad_at_apache.org>
Date: Tue, 22 Oct 2019 14:46:34 +0100

Stefan Sperling wrote:
> [...] it sounds like we
> are very close to having full support for Python 3 on trunk already or
> will have it soon. Which means it will be ready in time for 1.14 LTS as
> originally scheduled. Is that really not enough?

Stefan, thank you for articulating so clearly, especially about Python2
EOL not being the end of the world and about the value of adhering to
regular releases.

Further thoughts...

Mark wrote,
> I thought the frequent release/LTS plan was a worth a try, I
> just do not see where it is working out and yielding benefits.
> Our activity and contributions continues to go down, not up.
> The releases are underwhelming.

It's true that 1.13 is "essentially empty" in terms of new features.
However, after making changes aimed at improving participation, it takes
time to see results. I would like to point out we have gained two new
enthusiastic contributors (Nathan, Yasuhito) this year.

Prompted by Nathan's "wacky idea": When the time comes for a regular
release, if there are no changes that require a new minor version, then
it makes sense we should just issue a patch release and not bump the
minor version number.

I compared {1.12.x,1.13.x}/subversion/include/ and saw one public API
change: the new svn_fs_ioctl() and its related declarations. That means
we do need a new minor release. On another occasion, if we were to
review sooner and find a situation like that, we might decide to remove
that public change (if that's an option), on the principle that we
should prefer a patch release. It is too late to consider changing it
for this release, but we should start looking out for that situation
arising in future, if we decide that's a good variant of the release

While I object to postponing the current release, I am very open to
agreeing a wide range of changes to our release strategy for the next
releases. I agree with Mark's point that the current release strategy
is not right for the project and I think we should try to find a better
approach. That needs discussion in a separate thread.

- Julian
Received on 2019-10-22 15:46:38 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.