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 process.
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
