Den tors 23 juli 2026 kl 05:04 skrev Nathan Hartman < [email protected]>:
> 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 agree. In Lynx, which AFAICT does not support <details>, the table is shown directly. (That is also how the menu works by the way). > 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. > Looks nice! I think the arrow is acceptable but maybe the text can be a bit more explicit that you can expand the table? [[[ -<p>The following table compares the features supported by the Automake, CMake, -and vcproj build systems as of the 1.15.0 release:</p> +<p>To see a full comparison of the features supported by the Automake, CMake, +and vcproj build systems as of the 1.15.0 release, please expand the table below.</p> -<details><summary>Build System Comparison</summary> +<details><summary>Build System Comparison table</summary> ]]] Regarding highlighting of the Yes/No/NA-boxes, feel free to add something in the CSS. We already have something called a task-table but it is only suitable to highlight a complete row (you set the class "completed" on the <tr> element as far as I understand). How about something like this? [[[ Index: docs/release-notes/1.15.html =================================================================== --- docs/release-notes/1.15.html (revision 1936512) +++ docs/release-notes/1.15.html (working copy) @@ -910,9 +910,9 @@ <tr> <td>Auth module</td> <td>KWallet (KDE 4)</td> - <td>yes</td> - <td>no</td> - <td>N/A</td> + <td class="completed">yes</td> + <td class="unfinished">no</td> + <td class="na">N/A</td> <td></td> </tr> <tr> Index: style/site.css =================================================================== --- style/site.css (revision 1936511) +++ style/site.css (working copy) @@ -333,6 +333,21 @@ vertical-align: super; } +.completed::before { + content: "\2714 "; + color: green; +} + +.unfinished::before { + content: "\2716 "; + color: red; +} + +.na::before { + content: "\2723 "; + color: orange; +} + /* * Hide class="sectionlink", except when an enclosing heading * has the :hover property. ]]] Cheers, Daniel
