On Thu, Jan 9, 2014 at 8:20 AM, Richard Hipp <d...@sqlite.org> wrote:
It has been a few months since the last official release of Fossil. I > wonder if we should consider publishing trunk as the official version 1.28? > I realize I am responding to this a little late, but, hey, as a non-code-contributing blowhard, why should I let a little thing like that stop me? (*cough*). More seriously, this response is in light of all messages on this thread (at least, according to gmail) through Mark Jannsen's of Mon, Jan 13, 2014 at 5:17 PM (I don't know if that's my local time, or his, or what). (1) I think that, if the Fossil devs wish to make a release version of Fossil incorporating a non-release (e.g. "development", for some value of the word development) version of SQLite included as an embedded code copy, then that is fully their right to do so. They have the right to ship Fossil source code with whatever they wish to ship it with. (And again the right to support using Fossil *only* with whatever version of SQLite they wish to support it with!) Moreover, I *am* sympathetic to Dr. Hipp's desire for Fossil, as used by real end users in the field, to be used with a non-release version of SQLite, so as to better test SQLite before a release version of *it* is cut. I can understand his position, see things from his POV as a developer. However, I can also understand, and honestly agree with, the position of many end users and sysadmins that they do not want a "release" version of Fossil to make use of a non-release version of SQLite, and the position of packagers of Fossil that they do not want to have to support use with non-release versions of SQLite. No matter *what* Dr. Hipp says about the stability and safety even of development versions of SQLite (at least, of tagged development versions), and I am quite willing to take his word for this mind you, the typical end-user has been taught that anything labeled "alpha", "beta", etc is not to be trusted with precious or irreplaceable data. (Much like, these days, many people feel the same way about any software with a release version ending in ".0", e.g. "6.0", "7.0", etc.) And, unfortunately, the Fossil upstream devs are not in a position to force end-users to use or packagers to package software they are uncomfortable with -- the end-users and packagers can always vote with their feet. (2) Given (1), I fully expect that the packagers of Fossil for FOSS Unix/Linux distributions will *not* package it to make use of any latest trunk / development version of SQLite, but will instead only package it to use and depend on a stable release version. (Whether this is whatever code is shipped embedded with Fossil, or whether it's whatever version of SQLite they choose to ship with the distribution they are working on, is up to each individual packager of course.) I see that, at least as of the moment I write this, that the prospective Fossil 1.28 appears to still have the capability for --disable-internal-sqlite so that even if it were shipped with an embedded code copy of a non-release version of SQLite a packagers could choose to use the system provided version of SQLite. (I also note from the timeline that the prospective 1.28 does appear to have a release version of SQLite embedded.) However, if --disable-internal-sqlite were removed, and if the embedded code copy of SQLite was a non-release version, I'd be willing to bet money (a small amount anyway) that the vast majority of (if not all) packagers would rip that out and use a stable version of SQLite instead in their package as distributed by their distribution. (Which, after all, is *their* right, they only have to support for their end users what *they*, the packagers, want to support, and not what the Fossil upstream devs wish to support. The upstream devs do not have to assist the packagers in this, of course.) (3) I have a proposal to try to accommodate both the desires of packagers and end-users of release versions of Fossil to depend only on release versions of SQLite, *and* Dr. Hipp's desire for users to use Fossil with a recent (tho perhaps not heavily-bleeding-edge) non-release version of SQLite so as to get better testing of SQLite in the wild. However, I'll suggest that proposal in a different message. (4) I see it is planned that Fossil 1.28, as distributed by Fossil upstream, will require a minimum version of SQLite 3.8.2 per Check-in [f96162b06b] for branch-1.28. Fair enough. Distribution packagers, if they need Fossil 1.28 to work using older versions of SQLite, will have to make the appropriate patches; if Fossil upstream does not want to support / accept those patches, they don't have to. I think it might be a good idea to also do a _compile-time_ check to insure SQLite is at the required minimum at time of compilation; I assume this is feasible to do. And, of course, this upgraded requirement should all be documented in the release notes. (5) Re the performance issue related to WITHOUT ROWID tables, if you aren't going to address this (which seems perfectly reasonable to me mind you if it has no practical significance), it probably ought to at least be mentioned in the applicable release notes as a "will not fix in this release". (6) Re Jan Njitmans' comment early in the thread that using --disable-internal-sqlite allows a Fossil 1.28 binary, compiled to use SQLite 3.8.2 as an external library, could be used with SQLite 3.8.3 as a drop-in replacement, isn't this true only if 3.8.2 and 3.8.3 have the same ABI, function signatures, identical .h files, all that? Otherwise, 1.28 would have to be recompiled to account for 3.8.3's altered .h file (even if that's only a timestamp issue, because make). True? Or am I mistaken somehow? (Not that this really matters, mind you...) Thanks for your time. Hope this is of some use, interest. Joseph
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
