On Wed, Jul 22, 2026 at 6:03 PM Thomas Åkesson <[email protected]> wrote: > > > > > On 22 Jul 2026, at 18:48, Nathan Hartman <[email protected]> wrote: > > > > On Wed, Jul 22, 2026 at 12:11 PM Daniel Sahlberg > > <[email protected]> wrote: > >> > >> Den ons 22 juli 2026 kl 17:59 skrev Nathan Hartman > >> <[email protected]>: > >>> > >>> On Wed, Jul 22, 2026 at 11:24 AM Ivan Zhakov <[email protected]> wrote: > >>>> > >>>> On Wed, 22 Jul 2026 at 17:26, Nathan Hartman <[email protected]> > >>>> wrote: > >>>>> > >>>>> On Sat, May 16, 2026 at 3:18 PM Ivan Zhakov <[email protected]> wrote: > >>>>>> > >>>>>> On Sat, 16 May 2026 at 20:19, Nathan Hartman > >>>>>> <[email protected]> wrote: > >>>>>>> > >>>>>>> r1934265 (improving the CMake text in INSTALL) reminded me that CMake > >>>>>>> is not yet mentioned in the 1.15.x Release Notes. > >>>>>>> > >>>>>>> I'd like to add it there--after all, it is a new major (and long- > >>>>>>> requested!) feature in 1.15.x! > >>>>>> > >>>>>> +1! > >>>>>> > >>>>>>> > >>>>>>> But I've lost track of where it is > >>>>>>> currently. Has it reached parity with the autotools build, e.g., being > >>>>>>> able to build all the bindings? Any current limitations I should > >>>>>>> document? > >>>>>>> > >>>>>> > >>>>>> A week ago I created document to summarize features supported by > >>>>>> different Subversion build systems. > >>>>>> > >>>>>> Google Sheet document: > >>>>>> https://docs.google.com/spreadsheets/d/1goa9mrX75RhqQLSsNAr9z6G6cqDvUMDe5xWDJYG99cg/edit?gid=0#gid=0 > >>>>> > >>>>> > >>>>> Is this spreadsheet considered the source of truth for the status of > >>>>> the CMake build? If so, can/should I link to it from the Release > >>>>> Notes? > >>>> > >>>> > >>>> I made this document just to show the current state in trunk@HEAD, so > >>>> I'm not sure it fits well in the release notes as-is. I would also say > >>>> this information is too detailed for them. > >>>> > >>>>> Alternatively, we could move this to the CWIKI, or turn it into > >>>>> a HTML table and put it in the release notes directly, or... any other > >>>>> ideas?? > >>>>> > >>>> > >>>> One problem with having an external document/wiki page it that it needs > >>>> to be maintained and kept up-to-date, or it will start showing outdated > >>>> information. But if we do want it in the release notes, maybe it could > >>>> be embedded as a plain HTML table. That would match the other parts of > >>>> the release notes and doesn't need updating, because it is a > >>>> point-in-time snapshot. > >>> > >>> If CMake support continues to improve during the course of the 1.15 > >>> release line (e.g., adding ability to build the JavaHL bindings, > >>> KWallet/Keyring/Keychain, test with ra_svn/ra_serf, etc.) would we > >>> backport those things to the 1.15.x branch and release them in future > >>> 1.15.x patch releases? That would affect how the table should be > >>> presented, and whether we need to remember to update it. > >>> > >>> For now (in r1936491) I have gone ahead and placed the table in the > >>> 1.15 release notes, so we can see what that would look like. If we > >>> don't like it, we can take it out of there and put it in some other > >>> place. I like DSahlberg's idea of a separate buildsystems.html file, > >>> but then we have to remember to keep it updated. So, we'll see. > >>> Feedback welcome and I'll be happy to revert r1936491 if we don't like > >>> it. > >>> > >> > >> Actually, I like Ivan's idea better... If we backport additional features, > >> we can update the table "from 1.15.2". Having the table in the release > >> notes, we can update it when we release 1.16 to just say "Yes" on anything > >> that was added in a patch release. > >> > >> Only downside is the page is longer than it already was. Does it make > >> sense to hide the table by default and only show it if someone click a > >> link to expand it? > >> > >> (And before somebody cry "NO JAVASCRIPT", we already do this with the menu > >> in narrow-screen layout. It goes something like this: The hamburger is a > >> checkbox and the table is hidden by some CSS class that is dependent on > >> the state of the checkbox. If that is a good idea, I can see if I can > >> remind myself how it works) > > > > > > Well, it sounds like that won't use Javascript, so sure, +1 to that. > > > > Another thing that is lacking: the original Google Docs spreadsheet > > had cell background colors, like green for Yes and red for No. I lost > > all of this formatting when I exported the table to HTML and then > > search-and-replaced stuff in the resulting HTML to match how we do > > tables elsewhere. I wanted to reinstate the colors but it seems we > > don't currently have the CSS for it. I didn't want to just rush in and > > tack on a few more CSS classes in style/site.css, but I also didn't > > want to add CSS tags to every td tag. WDYT? > > Just want to mention the html <details> element that might be a viable > alternative. > > Thanks, > Thomas Å. >
Thanks for suggesting that. It's worth a try. According to [1] it's supported in all major browsers since 2020. Actually in most of them it was implemented long before that, in 2013 or so; Edge was the last to get it in 2020. Considering that browsers need to be updated all the time for security reasons, I think 2020 is ancient enough. I've wrapped the table in a details tag in r1936507; it's currently on the staging site. You can see it here: https://subversion-staging.apache.org/docs/release-notes/1.15.html#build-system-comparison I think we'll need to add some CSS to style the expansion arrow, to make it more obvious that a user action is needed to show the table. [1] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/details#browser_compatibility Cheers, Nathan
