Hi Fossil maintainers,

First of all, a big thank you for all the work you have done to benefit us, the mere users, and the community which relies on your work. With all the pleasantries aside, now, I would appreciate any quick update on the next release version of Fossil, likely to be 2.26. It's been more than five months since the last release, and it seems you guys merged a lot of extra work to benefit the users. So I really want to know when we can see it happening so that we can update it from our package managers or other places we used to download it. Also, it is very much appreciated if you give the information regarding the normal release cadence of Fossil-SCM.

FYI: I know we can get the latest snapshot directly from here or build it ourselves, but my intention here is to know the release timeline when it comes to official releases rather than developmental builds(I know they are totally stable and usable).

Thank you in advance.

drh started a topic on this about a month ago, with apparently an idea to start the 2.26 when things settle down (post 11, in that thread, also about a month ago).

Thank you. And can you tell me the normal release cadence for fossil-scm.

normal release cadence for fossil-scm

I have no particular insight on this query, but have always assumed that the schedule follows the When it's ready™ release system.

Ok, thank you.

If you visit the Fossil source timeline at https://fossil-scm.org/home/timeline you might notice a mark on one of the entries there that says: "← This is me!". That is the specific version of Fossil that is running on the server. As I type this, the server is running the very latest check-in.

I say this to encourage you to do likewise, and run the very latest Fossil check-in (or at least whenever it is that Fossil is running for itself) on your systems too. In this way, you help us to beta test. Please do not wait until an official release, then complain that your favorite obscure feature was broken. Let us know early, so that we can fix it before the release.

When will the next release occur? I'm not sure. I keep thinking of things to add to the current release. I made notes on four new improvements I need to make to the fossil server command just last night....

Thank you Mr. Hipp. I will try to do the same.

When will the next release occur? I'm not sure. I keep thinking of things to add to the current release. I made notes on four new improvements I need to make to the fossil server command just last night....

As my personal recommendation: I wouldn't wait too long.

The reason is, that a release with a version number attached is a more canonical form of binary. Even if building yourself is easy (and it is for fossil), if not needed it probably won't happen. Before I started to hack fossil in January I ran the version from my distribution (void linux) on my personal machine and on the Debian server which would be an older version I put the latest release I downloaded from the website. I guess most will do something similar.

Also, security bugs/CVEs will more likely be reported against release versions than against a checkin hash. In general it is easier to say "I encounter a bug with version 2.25", than to say "I encounter a bug with e3c58afb9d". At least fossil is nice enough to report the checkin hash it is built with, but most will still just take the version number.

The release logs say that over the past years fossil released between two or four times a year. I think that is fine, half a year between releases is OK. If you approach or pass the 6 month line though you should consider a release, so that distros and end users don't fall too much behind.

Just my 2 cents, you can handle it however you want. This is just the reasoning I can give for not waiting too long.

Edit: BTW, this is what distros are running. Some distros are behind, but quite a few are using the newest release. https://repology.org/project/fossil/versions

I'd be willing to put out a new pre-release snapshot similar to the current 2025-03-13 snapshot, just with an additional month's worth of enhancements.

One thing holding me back from that: I cannot get the Windows build to work with OpenSSL-3.5.0. It works fine with OpenSSL-3.4.1, but when I link against OpenSSL-3.5.0, things like "fossil sync" become no-ops. Can somebody who is Windows-based please help by debugging that problem?

I can confirm the failure. It's a crash (memory access violation) in the OpenSSL code to use the Windows certificate store.

The feature was enabled in Fossil by these check-ins, and backing out the changes resolves the problem, but also brings back the "accept this cert and continue (y/N/fingerprint)?" prompts.

Seems like a bug in OpenSSL 3.5.0?

I recommend sticking to OpenSSL 3.4.1 until this is resolved, for user comfort.

I filed a bug with OpenSSL: https://github.com/openssl/openssl/issues/27355

Thank you very much!

Yes, I think this is for the pros.

Even with full debug symbols available for both Fossil and OpenSSL, and being able to step around in the source code, I can't figure out what's going on, right now, with my rookie skills. Interesting exercise!

The OpenSSL devs are evaluating a fix and are asking for feedback, and I can confirm that the suggested patch resolves the problem.

(I'm sorry I don't have a GitHub account to post there directly.)

Not sure how to handle this situation in Fossil (assuming OPENSSL_VERSION_NUMBER will be increased for the next OpenSSL release that contains the fix):

• Abort with a compiler error (#error ... OpenSSL 3.5.0 ...) if OPENSSL_VERSION_NUMBER == 0x030500000?

• Disable the winstore feature if OPENSSL_VERSION_NUMBER == 0x030500000?

The latter probably causes confusion, as it looks like something is broken.

I think, disable the winstore feature for version 3.5.0.

#if OPENSSL_VERSION_NUMBER>=0x030200000 && OPENSSL_VERSION_NUMBER!=0x030500000

Or, since distros will likely use a shared library for OpenSSL, perhaps we should check the version number at run-time instead of at compile-time. I don't know how to do that off the top of my head, but we should be able to figure it out easily enough.

Yeah, seems like a good idea to recommend reporting bugs with the output of fossil version.