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) Cheers, /Daniel
