Preparing for Subversion 1.15.0-rc4 (was: Re: Subversion 1.15.0-rc3 up for testing/signing)

"Evgeny Kotkov via dev" <[email protected]> Fri, 31 Jul 2026 21:27:00 +0200
Newsgroups gmane.comp.version-control.subversion.devel
Message-ID <CAP_GPNgVWTni9z0P=Q8XGPYNZhxJrDzkqV8xHCm4sMtTuPzh8w@mail.gmail.com>
Hi all,

I think it's time for us to start preparing for Subversion 1.15.0-rc4.

I propose that we try to make RC4 the final release candidate, and defer
everything that shouldn't strictly go to .0 until the next patch release.

Here's a shortlog of all current changes from 1.15.0-rc3:

- [r1936635] Bump minimum CMake required version to 3.20
- [r1936306] Remove the ctypes bindings code
- [r1936337] Parse dumpfile property length as unsigned integers
- [r1936304] cmake: Fix tests failing with SVN_TEST_CHECK_XML_SCHEMA=OFF
- [r1936132] cmake: Sort target conditions to generate stable targets.cmake
- [r1936038] Don't use full path in the generated config_keys.inc file
- [r1932158] Properly use const string pointers
- [r1936310] Remove backport.pl
- [r1936214] Remove the build-svn-deps-win.pl script
- [r1936214] Remove tools/dev/wc-format.py
- [r1936610] Update and verify Simplified Chinese translation
- [r1936218] Update and verify Swedish translation

Neither of these changes look destabilizing per our definition [1]
("A potentially destabilizing change is one which could affect many parts
of Subversion in unpredictable ways, or which involves adding a substantial
amount of new code"), so I don't think we need to extend the soak period.

I also took a look at 1.15.x/STATUS, and neither of the entries look like
blockers for the final release.

The remaining open question is the JavaHL tests issue, also discussed in
[2] and [3]:

> If built with --with-junit the install-javahl target succeed.
>
> It is caused by r1934378 which backported r1933892.
>
> As noted in the other thread, Ubuntu and Fedora seems to build with
> --with-junit and FreeBSD builds without.
>
> I'm not sure if this is serious enough to block the release (in which
> case we might want to revert r1934378) or if it is enough to note as a
> known issue. It will cause issues for FreeBSD but it is quite easy to
> work around.

I am a bit out of context here, so two questions for those closer to it:

1) Is this a regression against 1.14.x?  Based on the description, it
   looks like one, because previously the package did not include the
   tests and the build worked without --with-junit.

2) If so, should we revert r1934378 on the 1.15.x branch and postpone the
   change until 1.16?  (Since it was a backport rather than something that
   originated on the branch.)

Once this part is resolved, I can start preparing to roll RC4.

[1]: https://subversion.apache.org/docs/community-guide/releasing.html#release-stabilization
[2]: https://lists.apache.org/thread/6qvs9r91lfjy8hjzmqgkj6xh1hnwbkp8
[3]: https://lists.apache.org/thread/c7nncmb28vbc9gmfvpj4d0dwk0h4711y


Thanks,
Evgeny Kotkov