Re: Preparing for Subversion 1.15.0-rc4 (was: Re: Subversion 1.15.0-rc3 up for testing/signing)
Branko Čibej <[email protected]> Sat, 1 Aug 2026 00:41:30 +0200
| Newsgroups | gmane.comp.version-control.subversion.devel |
|---|---|
| Organization | The Apache Software Foundation |
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --------------24km5XbUSVUI6FG8EVm3PfgS Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 --------------24km5XbUSVUI6FG8EVm3PfgS Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body> <div class="moz-cite-prefix">On 31. 7. 2026 21:53, Daniel Sahlberg wrote:<br> </div> <blockquote type="cite" cite="mid:CAMHy98P5mqwZKahd71UZ1xXKvqdLN9DMBtgzmy8huLFeSQWgxA@mail.gmail.com"> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> <div dir="ltr"> <div dir="ltr"><span style="background-color:transparent">Den fre 31 juli 2026 kl 21:28 skrev Evgeny Kotkov <<a href="mailto:[email protected]" moz-do-not-send="true" class="moz-txt-link-freetext">[email protected]</a>>:</span></div> <div class="gmail_quote gmail_quote_container"> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br> <br> I think it's time for us to start preparing for Subversion 1.15.0-rc4.<br> <br> I propose that we try to make RC4 the final release candidate, and defer<br> everything that shouldn't strictly go to .0 until the next patch release.<br> <br> Here's a shortlog of all current changes from 1.15.0-rc3:<br> <br> - [r1936635] Bump minimum CMake required version to 3.20<br> - [r1936306] Remove the ctypes bindings code<br> - [r1936337] Parse dumpfile property length as unsigned integers<br> - [r1936304] cmake: Fix tests failing with SVN_TEST_CHECK_XML_SCHEMA=OFF<br> - [r1936132] cmake: Sort target conditions to generate stable targets.cmake<br> - [r1936038] Don't use full path in the generated config_keys.inc file<br> - [r1932158] Properly use const string pointers<br> - [r1936310] Remove <a href="http://backport.pl" rel="noreferrer" target="_blank" moz-do-not-send="true">backport.pl</a><br> - [r1936214] Remove the <a href="http://build-svn-deps-win.pl" rel="noreferrer" target="_blank" moz-do-not-send="true">build-svn-deps-win.pl</a> script<br> - [r1936214] Remove tools/dev/wc-format.py<br> - [r1936610] Update and verify Simplified Chinese translation<br> - [r1936218] Update and verify Swedish translation<br> <br> Neither of these changes look destabilizing per our definition [1]<br> ("A potentially destabilizing change is one which could affect many parts<br> of Subversion in unpredictable ways, or which involves adding a substantial<br> amount of new code"), so I don't think we need to extend the soak period.<br> </blockquote> <div><br> </div> <div>+1</div> <div> </div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> I also took a look at 1.15.x/STATUS, and neither of the entries look like<br> blockers for the final release.<br> </blockquote> <div><br> </div> <div>+1 (although I'd prefer to see some of them included)</div> <div> </div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> The remaining open question is the JavaHL tests issue, also discussed in<br> [2] and [3]:<br> <br> > If built with --with-junit the install-javahl target succeed.<br> ><br> > It is caused by r1934378 which backported r1933892.<br> ><br> > As noted in the other thread, Ubuntu and Fedora seems to build with<br> > --with-junit and FreeBSD builds without.<br> ><br> > I'm not sure if this is serious enough to block the release (in which<br> > case we might want to revert r1934378) or if it is enough to note as a<br> > known issue. It will cause issues for FreeBSD but it is quite easy to<br> > work around.<br> <br> I am a bit out of context here, so two questions for those closer to it:<br> <br> 1) Is this a regression against 1.14.x? Based on the description, it<br> looks like one, because previously the package did not include the<br> tests and the build worked without --with-junit.<br> </blockquote> <div><br> </div> <div>In my opinion it is a regression. </div> <div><br> </div> <div>Previously it was possible to build without --with-junit and in that case the JAR didn't include the tests. <span style="background-color:transparent">If build with --with-junit, the JAR included the tests.</span></div> <div><br> </div> <div>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.</div> <div><br> </div> <div>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.</div> <div><br> </div> <div>In order of preference:</div> <div>- 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.</div> <div>- If tests are included, I'd want configure to ensure junit is found if --enable-javahl (instead of a build failure).</div> <div>- 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.</div> <div><br> </div> <div>For me, one of these is required before I will sign RC4.</div> <div><br> </div> <div>(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).</div> <div> </div> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> 2) If so, should we revert r1934378 on the 1.15.x branch and postpone the<br> change until 1.16? (Since it was a backport rather than something that<br> originated on the branch.)<br> </blockquote> <div><br> </div> <div>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.</div> </div> </div> </blockquote> <br> <br> 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.<br> <br> -- Brane<br> <br> </body> </html> --------------24km5XbUSVUI6FG8EVm3PfgS--