Fossil version 2.25 came out a little over four months ago on 2024-11-06. Changes since then (as I write these words):

• 389 check-ins on paths between the 2.25 release and the latest trunk. The graph.
• 125 files modified, with 15699 insertions and 8130 deletions.
• Perhaps the biggest change log that we've ever had.

It is customary to do Fossil releases shortly follow after SQLite releases, so that the SQLite built into Fossil is of the latest release. But right now, we are mid-cycle for SQLite, and the SQLite running in Fossil at the moment is labeled as 3.50.0 2025-02-15. I don't want to "downgrade" to SQLite 3.49.0. Even so, I'd like to do a new Fossil release soon.

Who would object to that?

No objections from me. Nice job to all the developers.

Couple curiosity questions...

389 check-ins on paths between the 2.25 release and the latest trunk.

The version-2.25 page takes you here: https://fossil-scm.org/home/info/name=version-2.25 and displays No such object: name_version-2.25
Is that expected?

125 files modified, with 15699 insertions and 8130 deletions.

How'd you calculate that?

The graph.

When i click that link to open in a new tab, i can see the graph, but if I copy the link and paste into a new tab, it wants me to login.
How'd you bypass the robot test?

https://fossil-scm.org/home/info/name=version-2.25 and displays No such object: name_version-2.25 Is that expected?

Where are you seeing that link? It's missing a "?" before the name. Try either of:

• https://fossil-scm.org/home/info/version-2.25
• https://fossil-scm.org/home/info?name=version-2.25 (is equivalent: fossil internally assigns everything after info/ to the "name" URI parameter)

I had the same question, Stephan. Then Daniel checked in the fix and I immediately understood. :-)

Perhaps the biggest change log that we've ever had.

Could be also containing the mention of the new ability to attach special wikis to tickets.

Which brings me to the question: what is customary in adding to the changelog? Should I change it on the branch so it is merged with the feature? Or will it be added when the branch is merged to trunk?

Could be also containing the mention of the new ability to attach special wikis to tickets.

i thought i had added that to the change log when merging that branch, but apparently neglected to. When attempting to do so a moment ago i wasn't happy with my description, so will ask you to please add an appropriate entry to www/changes.wiki.

i wasn't happy with my description

Dunno if you like mine better, but there it is.

I hadn't had cloned fossil yet on this laptop, so the Hotel WLAN got to real good use suddenly.

I've noticed the check-in to remove markup from comments printed to the CLI has quite some side-effects.

For example, it seems to change the location where line-breaks are inserted (that is, it affects line length calculation) for some comments that don't contain any markup at all.

Command for my tests:

fossil timeline --limit=0 --width=N

I've run this with the full Fossil history, with different values for N, and then compared the results with and without the referenced check-in.

I've just had a very limited amount of time for this, so far, and I couldn't find anything destructive at first glance, but I'd like to do more investigations, at least to understand what's going on.

Maybe it's worth to give the new comment mangling some time for field testing before the next release?

There is also a problem with .fossil-setting/manifest in that its value is not getting picked up by db_get_manifest_setting(), and consequently, if that file gets created and set to "on", the Git-export is incorrectly omitting the "manifest" and "manifest.uuid" files. See https://github.com/drhsqlite/pikchr/issues/6 for the bug report.

I need to chase this to ground before doing a release.