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).
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.
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?
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.
18 comments
[ 1.8 ms ] story [ 52.9 ms ] threadSo it modifies SQLite to add various features, thus deviating from SQLite as it is while still using it as its base? That's what a fork is.
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.
...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).
https://sqlite.org/forum/forumpost/9aa5e1dcffde1336
See the "preliminary results" link.
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?
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.