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
