I thought it was sufficient to implement a different backend, but apparently that's not the case. I hope the direction they push is to extend the vtable API to make it capable of their use case.
Just maintain a dev branch on SQLite, the same as on, say, NGINX, and only merge into mainline after > 3 years of use by the lots of users that are safe using dev.
Will get it battle tested better and fatser, and in the hands of far more users. Why have a not-a-fork fork?
Aside, anyone used the java sqlite driver https://github.com/xerial/sqlite-jdbc in production (webapp with multiple users)? Has the driver been reliable?
The "not forking" graphics look a lot more like forks then spoons or knives. Let's call that forking. Or if they insist on renaming monkey patching to something new: lets name it pitchforking or tridenting.
A fork implies that the projects are going diverge, which it seems they don't want to happen.
From a quick reading of that page I think the LumoSQL authors are making the effort to maintain their set of modifications as some kind of patch which will continue to be compatible with future SQLite versions as they are released.
> A fork implies that the projects are going diverge,
...which is exactly what you're doing when you branch off a release branch and start applying your own commits with no plan to merge them back to mainline.
> which it seems they don't want to happen.
They are already doing it. They are only arguing that they can reapply the same patches over the next release branch, but that doesn't really change anything.
If they want to stay as close as possible to upstream, you'd think they'd either keep it public domain, or else choose a public domain-equivalent license (such as MIT-0, 0BSD, CC0, etc).
I thought it was sufficient to implement a different backend, but apparently that's not the case. I hope the direction they push is to extend the vtable API to make it capable of their use case.