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? Thanks, Nathan
