2014/1/9 Richard Hipp <[email protected]>:
> I view Fossil as supporting SQLite, not the other way around. (Remember,
> that's why Fossil was original written!) As part of its role of supporting
> SQLite, Fossil serves as a test platform for the latest SQLite alphas. For
> that reason, I want Fossil 1.28 to have the very latest trunk of SQLite, not
> the most recent release.
I already expected that answer, and it's perfectly fine. As developer I
completely agree with that. But package maintainers prefer to
release Fossil with the most stable SQLite, they don't want to
play the role as SQLite testers. As (Cygwin) package maintainer
(for SQLite, not for Fossil) I completely agree with that.
There are two ways package maintainers can get what they
want:
- Replace Fossil's SQLite amagalmation with whatever they
want, probably SQLite 3.8.2 (maybe with backported bugfixes)
- Compile Fossil with --disable-internal-sqlite.
In both situations, the package maintainers are responsible
for whatever bug this introduces in Fossil.
The latter has the advantage that no new Fossil binary
has to be built when SQLite 3.8.3 is released. Fossil will
always follow the latest stable SQLite automatically.
I hope this is an important argument for keeping
the --disable-internal-sqlite option.
Regards,
Jan Nijtmans
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
