Re: Adding CMake to 1.15.x release notes

On 22. 7. 2026 18:11, Daniel Sahlberg 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)

I prefer the way it's done on the downloads page, where the dropdown to 
select a mirror definitely does support no-script mode.

-- Brane