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

Timofei Zhakov <[email protected]> Fri, 31 Jul 2026 23:15:00 +0200
Newsgroups gmane.comp.version-control.subversion.devel
Message-ID <CAPD1kXSFEyP8B7x5CUS-MM6CJm6s9D3pHsNuoz8PeHi7FtjJEg@mail.gmail.com>
On Fri, Jul 31, 2026 at 9:28=E2=80=AFPM Evgeny Kotkov via dev
<[email protected]> wrote:
>
> 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=3DOF=
F
> - [r1936132] cmake: Sort target conditions to generate stable targets.cma=
ke
> - [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 substanti=
al
> 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 tha=
t
>    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#re=
lease-stabilization
> [2]: https://lists.apache.org/thread/6qvs9r91lfjy8hjzmqgkj6xh1hnwbkp8
> [3]: https://lists.apache.org/thread/c7nncmb28vbc9gmfvpj4d0dwk0h4711y

Why not roll 1.15.0 straight away? I thought it was the original plan.

I guess it makes sense due to the amount of changes since rc3 and
especially the release blockers that had to be addressed. So if we
decide to go this way, I support it with my +1. I think it's safe to
say that all the concerns we had last time are now fixed.

--=20
Timofei Zhakov