On Wed, 22 Jul 2026 at 19: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? > > I have added styles for semantic colors in r1936517 <https://svn.apache.org/r1936517>. And added them to Build System Comparison table in r1936518 <https://svn.apache.org/r1936518>. -- Ivan Zhakov
