Re: Adding CMake to 1.15.x release notes

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