Re: Preparing for Subversion 1.15.0-rc4 (was: Re: Subversion 1.15.0-rc3 up for testing/signing)
Daniel Sahlberg <[email protected]> Fri, 31 Jul 2026 21:53:00 +0200
| Newsgroups | gmane.comp.version-control.subversion.devel |
|---|---|
| Message-ID | <CAMHy98P5mqwZKahd71UZ1xXKvqdLN9DMBtgzmy8huLFeSQWgxA@mail.gmail.com> |
--0000000000002613ba0657ed8a59 Content-Type: text/plain; charset="UTF-8" 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 > - [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. > +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. > 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 [4]: https://inside.java/2024/12/09/quality-heads-up/ > > > > Thanks, > Evgeny Kotkov > Thanks, Daniel --0000000000002613ba0657ed8a59 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><span style=3D"background-color:transpare= nt">Den fre 31 juli 2026 kl 21:28 skrev Evgeny Kotkov <<a href=3D"mailto= :[email protected]">[email protected]</a>>:</span></di= v><div class=3D"gmail_quote gmail_quote_container"><blockquote class=3D"gma= il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2= 04,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 releas= e.<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=3DOFF<= 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=3D"http://backport.pl" rel=3D"noreferrer" targe= t=3D"_blank">backport.pl</a><br> - [r1936214] Remove the <a href=3D"http://build-svn-deps-win.pl" rel=3D"nor= eferrer" target=3D"_blank">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 pa= rts<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>=C2=A0</div><block= quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1= px 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<b= r> blockers for the final release.<br></blockquote><div><br></div><div>+1 (alt= hough I'd prefer to see some of them included)</div><div>=C2=A0</div><b= lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le= ft: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 wh= ich<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?=C2=A0 Based on the description, it<= br> =C2=A0 =C2=A0looks like one, because previously the package did not include= the<br> =C2=A0 =C2=A0tests and the build worked without --with-junit.<br></blockquo= te><div><br></div><div>In my opinion it is a regression.=C2=A0</div><div><b= r></div><div>Previously it was possible to build without --with-junit and i= n that case the JAR didn't include the tests.=C2=A0<span style=3D"backg= round-color:transparent">If build with --with-junit, the JAR included the t= ests.</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><d= iv>- I'd prefer to see the "should tests be included in the JAR&qu= ot; be settled once and for all. It is not a release blocker.</div><div>- I= f 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 th= is 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 require= d 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 backpo= rted to 1.15 so we have to deal with that in 1.16 when we have reached a de= cision on the JAR contents).</div><div>=C2=A0</div><blockquote class=3D"gma= il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2= 04,204);padding-left:1ex"> <br> 2) If so, should we revert r1934378 on the 1.15.x branch and postpone the<b= r> =C2=A0 =C2=A0change until 1.16?=C2=A0 (Since it was a backport rather than = something that<br> =C2=A0 =C2=A0originated on the branch.)<br></blockquote><div><br></div><div= >It is not clear exactly WHEN this change (the JavaHL JAR being an automati= c 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><br= ></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;= border-left:1px solid rgb(204,204,204);padding-left:1ex"><br> Once this part is resolved, I can start preparing to roll RC4.<br> <br> [1]: <a href=3D"https://subversion.apache.org/docs/community-guide/releasin= g.html#release-stabilization" rel=3D"noreferrer" target=3D"_blank">https://= subversion.apache.org/docs/community-guide/releasing.html#release-stabiliza= tion</a><br> [2]: <a href=3D"https://lists.apache.org/thread/6qvs9r91lfjy8hjzmqgkj6xh1hn= wbkp8" rel=3D"noreferrer" target=3D"_blank">https://lists.apache.org/thread= /6qvs9r91lfjy8hjzmqgkj6xh1hnwbkp8</a><br> [3]: <a href=3D"https://lists.apache.org/thread/c7nncmb28vbc9gmfvpj4d0dwk0h= 4711y" rel=3D"noreferrer" target=3D"_blank">https://lists.apache.org/thread= /c7nncmb28vbc9gmfvpj4d0dwk0h4711y</a></blockquote><div>[4]: <a href=3D"http= s://inside.java/2024/12/09/quality-heads-up/">https://inside.java/2024/12/0= 9/quality-heads-up/</a></div><div>=C2=A0</div><blockquote class=3D"gmail_qu= ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20= 4);padding-left:1ex"><br> <br> <br> Thanks,<br> Evgeny Kotkov<br></blockquote><div><br></div><div>Thanks,</div><div>Daniel<= /div><div>=C2=A0</div></div></div> --0000000000002613ba0657ed8a59--