On 31. 7. 2026 21:53, Daniel Sahlberg wrote:
Den fre 31 juli 2026 kl 21:28 skrev Evgeny Kotkov
<[email protected]>:
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 <http://backport.pl>
- [r1936214] Remove the build-svn-deps-win.pl
<http://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.
+1
I also took a look at 1.15.x/STATUS, and neither of the entries
look like
blockers for the final release.
+1 (although I'd prefer to see some of them included)
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.
In my opinion it is a regression.
Previously it was possible to build without --with-junit and in that
case the JAR didn't include the tests. If build with --with-junit, the
JAR included the tests.
1.15.x can ONLY be built with --with-junit and, worse, configure gives
no indication if you don't use --with-junit but the build fail with an
error.
Clearly, 1.14.x can produce two distinctly different JARs (with and
without the test classes). 1.15.x is more consistent in that it will
ONLY produce JARs with the test classes.
In order of preference:
- I'd prefer to see the "should tests be included in the JAR" be
settled once and for all. It is not a release blocker.
- If tests are included, I'd want configure to ensure junit is found
if --enable-javahl (instead of a build failure).
- If we cannot get this done, I could probably live with this being
documented as a "known issue" in the release notes. It would affect
the FreeBSD build but not Ubuntu or Fedora.
For me, one of these is required before I will sign RC4.
(In all the above, I'm ignoring the CMake build. I don't think the
JavaHL support is backported to 1.15 so we have to deal with that in
1.16 when we have reached a decision on the JAR contents).
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.)
It is not clear exactly WHEN this change (the JavaHL JAR being an
automatic module) is required but non-automatic module is deprecated
as of Java 24 (released March 25). I think it would be nice to have
this fix included in the build since we don't know when 1.16 will be
released.
Given the frequency of our .0 releases, the automatic module thing is
IMO required for 1.15.0 because without it, JavaHL would probably be
broken by JRE 28 or 29. Maybe there's a way to do this while still
keeping the 1.14 behaviour, i.e., adding test classes to the JAR only if
tests (JUnit) were enabled in the configure command. Even though this is
kind of wrong. We then have time until 1.16.0 to figure out what to do
about JavaHL test classes.
-- Brane
