I just noticed that the Fossil version 2.11 change log is getting rather long. Should we go ahead and release version 2.11?

The concern is that we are smack in the middle of an SQLite release cycle, so the version of SQLite bundled with Fossil is 3.32.0-alpha. I do not have any concern about that, since the bundled SQLite is quite stable and passes all tests I have thrown at it. However, I've noticed that some others are bothered by bundling a non-release SQLite with an official Fossil release.

We could, in theory, back up the built-in SQLite to the official 3.31.1 release. But I am opposed to that. I prefer to have the very latest stable SQLite in each Fossil release.

So the question becomes: Should we release Fossil 2.11 now, even though it is bundled with SQLite 3.32.0-alpha, or should we defer releasing Fossil 2.11 for a couple more months until the official SQLite 3.32.0 comes out?

I’d’ve preferred to have released 2.11 months ago when SQLite was stable, but with this move to the forum for SQLite.org, aren’t we expecting a bunch of forum-related patches soon?

What if you just retrospectively tag a past checkin with version-2.11, and all this expected improvement can go into 2.12?

So the question becomes: Should we release Fossil 2.11 now, even though it is bundled with SQLite 3.32.0-alpha, or should we defer releasing Fossil 2.11 for a couple more months until the official SQLite 3.32.0 comes out?

Alpha schmalfa. Let's do 2.11 now and in a couple more months, if needed, we'll have 2.12.

Whoa... the sqlite forum is live! i am eagerly waiting to see what improvements that will drive to the forum, given its potential for much higher traffic than this one.

It is now 193 days and 379 check-ins since the last Fossil release. There have been some invasive changes to the sync protocol lately, so I'm not suggesting a new release "tomorrow" - the recent changes need to bake for a while. Still, it has been some time since we put something out. Experienced users know that it is safe and easy to download, compile, and use the latest trunk version of Fossil. But a lot of people will only use an "official release". So maybe we should think about doing another one.

My intent is to release Fossil 2.11 on or before Friday 2020-04-24 unless someone comes up with a good reason not to. The 2.11 release will include an alpha-version of SQLite 3.32.0.

How You Can Help

• Audit the recent configuration file name changes to ensure that they will not cause compatibility problems.

• Download the latest code and make sure it compiles cleanly on every platform you have access to.

• Use the latest code in your daily activities and verify that you do not have any new problems.

• Run test cases.

• Read through the documentation and point out (or fix) typos or errors and/or suggest improvements.

• Review all changes since the last release and make sure that everything looks to be ok. Suggest enhancements or clarifications to the change log, keeping in mind that we want a balance between brevity and completeness.

• Review diffs since the previous release looking for problems. Use a URL like shown below. (I'm making you copy-paste this link because it is expensive for the server to compute that diff, and I don't want a bunch of robots following it.)

          https://www.fossil-scm.org/fossil/vdiff?from=version-2.10&to=20200424

No problems compiling on OpenBSD -current (6.7 beta) or Windows with with Visual Studio 2017.

This release will be jam packed with many changes! Thanks everyone for the great work.

The 2.11 release will include an alpha-version of SQLite 3.32.0.

I know Fossil is also used as a test-bed for SQLite, and that SQLite
is one of the best tested software on the planet. But that seems to
go against conventional wisdom, to base a release on alpha dependencies.

Clearly SQLite releases more often that Fossil, which seems to mostly
assume users build from source. Given that, what prevents using an
officially released SQLite? I'm not complaining, just curious.

Anything special in SQLite 3.32 that Fossil needs?

Anything special in SQLite 3.32 that Fossil needs?

I don't know of anything in SQLite 3.32 that Fossil especially needs. But on the other hand, all of my testing of Fossil so far has been with the SQLite 3.32 alpha. I think it is better to release exactly what has been tested these past weeks, rather than dropping back to SQLite 3.31.1 and risk discovering some feature of SQLite 3.32 that Fossil depends on that I've overlooked.

Fly what you test and test what you fly.

Fossil 2.11 Is Postponed.

A bug was found in the subscription mechanism. An attacker was able to create a verified subscription without entering an email address that he controlled. This could have enabled a miscreant to subscribe some innocent third-party to receive email notifications, as a means of harassing that third-party.

The problem has now been fixed, but I want to do more testing and give the new code time to bake before I cut the release.

Estimated postponement: 5-7 days.

An email has been sent to "sean@example.com"

Probably a good idea to say this domain isn’t well known.

I was able to create an account on the forum and post this message without access to that faux address.

You should have received an email message containing a link that you must visit to verify your account. No email notifications will be sent until your email address has been verified.

Ah. Maybe I misinterpreted the fix. I can creat an account and post with it, it’s just that email notifications won’t be delivered/sent until the link is activated.

There is an option for that now. On the /Admin/Access page you can click on the "Email verification required for self-registration" radio button to turn that feature on and off. It defaults to off and that is how I have it set for this forum - "Off" - meaning that receipt of the confirmation email is not required in order to use the new account.

I could turn that on. That would mean that nobody would be able to post messages using a self-registered username until after they had received their confirmation email and clicked on the link. Do you think I should do that?

Do you think that the "Email verification required for self-registration" button should default to "on" rather than "off"?

Details:

The "Email verification required for self-registration" button controls the "selfreg-verify" setting. When that setting is on, users are still allowed to self-register, but the permission string is set to just "7" (ability to self-register) rather than giving them the full permissions normally available to self-registered users. The full permission set (controlled by the default-perms setting) is not given to the user until they click on the link the confirmation email.

In case of this forum, denying permissions to newly registered users will not prevent them from posting, since the users will still inherit the permissions from user "nobody" and "nobody" has permission to post (so that anonymous passers-by can post).

So I might need to do further work to prevent users from posting with a newly acquired identity until after they have confirmed their email....

And: What if the initial confirmation gets lost or doesn't go through. There ought to be some way for the new user to request a new confirmation email, perhaps with an alternative email address. (This would need to come with another captcha to prevent abuse.) That mechanism has not been put in place yet.

Should this all hold up the 2.11 release?

There is precedent for releasing without some features still a work-in-progress. As long as new features do not cause damage, I think it is ok to do a release even if the new feature has not yet reached its end-state. Hence, I am comfortable doing a release as-is, as soon as I am confident that there are no big security holes.

It might be better if we move Fossil to a two- or three-week release cycle. Every few weeks, we pick one of the recent trunk versions that seems especially stable and call it a "release". Maybe there is also a Long-Term Support (LTS) version that we keep around for longer, but the latest version is usually not more than a week or two old. That is more of the way that Fossil works anyhow. The SQLite project (for which Fossil was originally created) normally uses the latest trunk check-in of Fossil and I encourage other users to do the same. Perhaps we should formalize that idea by keeping an LTS version of Fossil on the download page, but also weekly builds. Thoughts?

Maybe this last section should be a separate forum thread? I'll do that....

Do you think that the "Email verification required for self-registration" button should default to "on" rather than "off"?

That certainly seems to be the default on practically all websites these days. But you have two interesting points:

1. Anon can post
2. There is no way to reset/rend subscription request at this time.

If the verify link is enabled, are messages moderated until after their first post?

The Release Schedule wiki page has been added, in an attempt to make the decision about when to do a release more concrete. Feedback is solicited.

To make up for the fact that there has not been a release lately, I have put a recent beta on the Download page.

I like that idea. Would you consider a link on index.wiki pointing this out?

Beta Test Requests

I am doing frequent beta builds on the Download Page. Please try them out. In so doing, you will be testing:

1. The upcoming 3.32.0 release of SQLite
2. The upcoming 2.11 release of Fossil
3. The procedures for constructing build products.

Please report any problems by replying to this post. Remember that a release can occur at any moment, so do not delay. Thank you for your attention!

Good call on preparing for a release of Fossil. 2.11 will be a great release.

The raspbian Fossil version doesn't work for me, but I think it's because I've compiled OpenSSL for a different application.

$ ./fossil 
./fossil: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory

$ ls -l /usr/local/lib/libssl.*
-rw-r--r-- 1 root root 670012 Sep 15  2019 /usr/local/lib/libssl.a
lrwxrwxrwx 1 root root     13 Sep 15  2019 /usr/local/lib/libssl.so -> libssl.so.1.1
-rwxr-xr-x 1 root root 537304 Sep 15  2019 /usr/local/lib/libssl.so.1.1

I am able to install from src:

 $ fossil version
This is fossil version 2.11 [a8098efebf] 2020-05-19 16:51:46 UTC

Actually, I just checked on a different pi and I'm still not able to run the binary you posted on my nearly unmodified pi:

$ ./fossil 
./fossil: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory

$ openssl version
OpenSSL 1.1.1d  10 Sep 2019

Looks like I have this file: /usr/lib/arm-linux-gnueabihf/libssl.so.1.1

The build procedure for Raspberry PI has been updated, and new builds (both the beta and version 2.10) for PI have been uploaded. Please try again using the latest PI binary and let me know whether or not the new one works for you.

Success!

$ ./fossil version -v
This is fossil version 2.11 [a8098efebf] 2020-05-19 16:51:46 UTC
Compiled on May 19 2020 12:13:09 using gcc-4.9.2 (32-bit)
Schema version 2015-01-24
Detected memory page size is 4096 bytes
zlib 1.2.8, loaded 1.2.11
hardened-SHA1 by Marc Stevens and Dan Shumow
SSL (OpenSSL 1.0.1t  3 May 2016)
FOSSIL_ENABLE_LEGACY_MV_RM
UNICODE_COMMAND_LINE
FOSSIL_DYNAMIC_BUILD
SQLite 3.32.0 2020-05-19 15:51:10 3117c1b5a9
SQLITE_DEFAULT_FILE_FORMAT=4
SQLITE_DEFAULT_WAL_SYNCHRONOUS=1
SQLITE_ENABLE_DBSTAT_VTAB
SQLITE_ENABLE_FTS4
SQLITE_ENABLE_FTS5
SQLITE_ENABLE_JSON1
SQLITE_ENABLE_LOCKING_STYLE=0
SQLITE_ENABLE_STMTVTAB
SQLITE_LIKE_DOESNT_MATCH_BLOBS
SQLITE_MAX_EXPR_DEPTH=0
SQLITE_OMIT_DECLTYPE
SQLITE_OMIT_DEPRECATED
SQLITE_OMIT_GET_TABLE
SQLITE_OMIT_LOAD_EXTENSION
SQLITE_OMIT_PROGRESS_CALLBACK
SQLITE_OMIT_SHARED_CACHE
SQLITE_THREADSAFE=0
SQLITE_USE_ALLOCA

I just downloaded 2.11-beta-202005191651 to bootstrap a build-from-source Fossil installation on a new machine. I was twice surprised to see the message:

use --repository or -R to specify the repository database

First, when I issued command:

$ fossil clone URL DB_FILE                                                                                                                             

and then when I issued command:

$ fossil open DB_FILE                                                                                                                                  

Apart from those two un{warranted|expected} warnings, everything seems fine.

I am not seeing that warning. Can you please send the exact commands you are using?

My mistake. The commands are scripted. When I run them directly in the shell, no warnings are emitted. I need to investigate further. Please disregard this report. Apologies for the noise.

There is an unexpected Error: sqlite3_close() returns 5: unable to close due to unfinalized statements or unfinished backups upon fossil close after a seemingly innocuous query. This occurs both with trunk's 0feb412869 (on Buster and Win10) as well as e.g. with an official 2.8 [d3bc4ee903] on Buster. Steps:

$ f init testclose.fossil
$ f open testclose.fossil
$ f timeline
=== 2020-05-22 ===
13:50:03 [f62b7fb47b] *CURRENT* initial empty check-in 
$ f sql
sqlite> select printf('%s',content('f62b7fb47b'));
'C initial\sempty\scheck-in
D 2020-05-22T13:50:03.497
...
'
sqlite> .quit
Error: sqlite3_close() returns 5: unable to close due to unfinalized statements or unfinished backups

sqlite3_close() returns 5: unable to close due to unfinalized statements or unfinished backups

The sql command has been doing that for some time now - at least 6 months.

The sql command has been doing that for some time now - at least 6 months.

Correction: more than a year (see also)

Should be fixed now on trunk.

Version 2.11 RC1 (Release Candidate #1) is now up on the download page. If no serious issues are discovered over the next few days, this will become the official 2.11 release.