On Mon, Jan 6, 2014 at 7:52 AM, Jan Nijtmans <jan.nijtm...@gmail.com> wrote:
> 2014/1/4 Richard Hipp <d...@sqlite.org>: > > (3) After SQLite 3.8.3 is released, release fossil 1.28 with > the EXACT SQLite 3.8.3 amalgamation included. > I assume you do not mean here that Fossil v 1.28 should be released concurrently with SQLite release v 3.8.3, but instead that Fossil v 1.28 should be released "when it is ready" on or after the moment that SQLite release v 3.8.3 is tagged (be that a day, a week, a month, whenever) such that the source for the SQLite release v 3.8.3 can be incorporated within the source for Fossil v 1.28. (4) Immediately after the fossil 1.28 release, add a runtime-check > for SQlite 2.8.2 (as suggested by Joe Mistachkin), and add > "WITHOUT ROWID" to whatever SQL statement it is useful. > Unconditionally! > I assume here (and below) you mean SQLite 3.8.2, not 2.8.2 (and 3.8.3 instead of 2.8.3). I also assume you mean here that it be a runtime check requiring that *at* *least* SQLite 3.8.2 is available to Fossil (e.g. "SQLite 3.8.2 *or later*"), rather than a runtime check requiring that SQLite 3.8.2 *exactly* be available to Fossil. (Otherwise, Fossil builds using the embedded code copy of SQLite would fail at runtime, because you've just specified the embedded code copy of SQLite for this version of Fossil is 3.8.3 and not 3.8.2.) May I ask why that run-time check cannot or should not be made in the release version of Fossil 1.28, rather than immediately after it is tagged such that it will only take effect in a release version for Fossil 1.29? Sure, it means that distributions cannot distribute Fossil 1.28 (as released by Fossil upstream) using a system-provided shared library version of SQLite until they have updated that system-provided shared library version of SQLite to 3.8.2 from whatever version they currently have (call it v XY.ZZY), but so what? Distributions are used to this sort of thing, applications requiring a version of a system-provided library more recent than the version they currently make available. The distributions will just have to (1) provide a new version of the system-provided shared library version of SQLite that is sufficiently recent for Fossil v 1.28's needs (presumably either SQLite 3.8.2 or 3.8.3 at their discretion); (2) make sure that all the other applications they distribute that depend on SQLite, which currently work with SQLite v XY.ZZY, will work properly with the new version of SQLite whatever it ends up being, and patch or update those other applications as necessary; (3) make Fossil 1.28, the new version of SQLite, and any new versions of other apps available to their end-users, which the end-users can update to if and as they see fit to. (Well, unless the distributions patch their copy of Fossil v 1.28 to use their copy of SQLite v XY.ZZY, but they do that at their own risk and are responsible for all support of that combination. Fossil upstream devs will not support that combination of software.) This will require all end-users to update their copy of SQLite and possibly other applications depending on SQLite if they want to use the new release version of Fossil, but again so what? That's what distribution packaging, and distribution software update tools, are all about; to make sure that sort of thing works, everything is consistent and supported, etc. > (5) Future official fossil release should contain an official released > SQLite amagalmation as well, but less frequent: There is > no need to make a new Fossil release after each SQLite > release. > I would agree that, unless part of the purpose (either explicit or implicit) for Fossil's existence is to act as a showcase and testbed for the latest and greatest available version of SQLite, there is no need to tie releases of Fossil to releases of SQLite. Release versions of Fossil should be made "when they are appropriate" and "when they are ready", which does not necessarily have anything to do with the release schedule of SQLite. Further, release versions of Fossil should not necessarily require using the latest and greatest release version of SQLite, unless features and bug-fixes only available in that version of SQLite are required by the release version of Fossil to be made. Instead, release versions of Fossil should only require using the oldest version of SQLite providing the features that version of Fossil needs which the Fossil devs *are* *willing* *to* *support* for that version of Fossil. (If the Fossil devs say "We only support using the latest and greatest release version of SQLite available at the time we made this release version of Fossil", well then so be it. The Fossil devs are volunteers, presumably not being paid (in general) to develop and support Fossil, and are not required to do anything they do not want to do.) In particular... If Fossil version M requires using SQLite version N, and if Fossil version M+1 does not require any features or capabilities new to SQLite version N+1, but instead still only requires the capabilities provided by SQLite version N to work properly ... then it should not be *necessary* for Fossil version M+1 to require SQLite version N+1. (If the Fossil devs do not *want* to support the combination of Fossil M+1 and SQLite N, well, that's a different issue.) I'll also note here, based on what you mention below, that a release version of Fossil should never depend on or provide as an embedded code copy a non-release or development of SQLite. Development versions of Fossil can do what they wish; if they want to depend on a moving target, then so be it. But release versions should not.) > > at (1): Supporting every SQLite 3.7.x release is madness, > SQLite 3.7.17 is more than 7 months old now, that should > be enough time for whatever distribution to upgrade to it. > I'll note that a stable release version of a distribution might well have a version of SQLite older than 3.7.17, but a stable release version of a distribution is also not going to be updating its version of Fossil either, so that's not a big deal. Just as one example... Debian has a variant of 3.7.13 in its current stable distribution, 3.8.2 in its testing distribution (which will eventually become the next stable distribution), and also 3.8.2 in its unstable distribution (where software is first uploaded and automatically promoted to testing after a period of time). > at (3): Advantage: official SQLite releases are better > tested than intermediate ones. Fossil 1.27 contains > a SQLite 2.8.1 beta with a bug which is crucial on > Cygwin. See: > <http://osdir.com/ml/sqlite-users/2013-12/msg00193.html> > This bug is discovered during release testing of > SQLite 2.8.2 (when I became Cygwin's SQLite maintainer), > if fossil would have been compiled with --disable-internal-sqlite > the bug would have been fixed now. > I am surprised to hear that a release version of Fossil would require (or provide as a private embedded copy) a development version of a library required by Fossil. I would have thought that a release version of any application whatsoever would depend only on presumably stable release versions of any libraries required by the application, and not on a development version of a library whose functionality is presumably subject to change. at (4): If SQLite 2.8.3 is released around February, then > a reasonable Fossil 1.29 release could be done > mid 1014. That's more than enough time for > whatever distribution to upgrade to SQLite 2.8.2. > And it means that starting one month from now > Fossil developers don't need to worry about > WITHOUT ROWID support: just use it > whenever appropriate. > A release version of Fossil (or any application) should use whatever version of a library provides the features needed by the developers for that version of their application. While distributions will appreciate it when an application does not gratuitously or unnecessarily raise its requirements for the minimum necessary version of a library, if an application really does need to raise its requirements, then so be it. (If the application is raising its requirements for a minimum library version solely because of bug fixes in the new version of the library, rather than because of newly available functionality, the application should probably indicate that somewhere. A distribution might back-port bug fixes from a new version of a library to an older version where they would not back-port new functionality. In this case, the old version of the library with the applicable bug fixes would probably be good enough for the application.) If that means the release version requires a newer version of the library than was previously available in a given distribution, then so be it. It's the problem of the distribution to provide the libraries a given version of an application needs, if they want to distribute that version of the application. (At least without the distribution patching the application such that it can work with an older version of the library. But, note, this will not necessarily be supported by the upstream developers of the application!) This may well mean that a potential end-user of the application, who is receiving the application via the distribution, may need to update significant parts of their system to use a new version of the application. (They might need to update system libraries the new version of the application requires; they might need to update other unrelated applications that depend on the system libraries that were just updated, repeat at necessary until everything is consistent again.) End users understand this; it's part of what it means, and indeed part of the point, of using a distribution -- the distribution integrates everything and does its best to make sure everything is consistent and reasonably interoperable. However... This DOES impose an obligation on the upstream developers of the application, too! Specifically... If the upstream developers state that they only require version N of a given library, then they MUST restrict themselves to using *only* features *provided by* version N, and not use any features provided by any later version, e.g. N+1 or later! If they want to use a feature only newly available in version N+1, this is fine, but then they have to *tell* people this by raising the minimum required version of the library! Likewise, if they want to *stop* supporting version N-1, this is also fine, but again then they have to *tell* people this by raising the minimum required version of the library! (If a distribution wants to use a given version of the application with a library older than the minimum required version as stated by the developers, this is the right of the distribution to do. And, if the distribution has a problem doing this, and asks the developers for help, all the developers have to do is say "We don't support that combination, sorry, you're on your own". The distributions are used to that, they know it's their problem.) at (5): This means that part of the pre-release > testing of every Fossil release should be a > test using --disable-internal-sqlite, in order > to verify that Fossil really works well with > the lowest SQlite version it is documented > to work with. I volunteer to do this pre-release > test. > I am surprised to hear that, before final release, proposed release versions of Fossil are not already tested to insure they do in fact work with the minimum version of SQLite the developers of Fossil state is required (whatever that minimum happens to be for the given proposed release version of Fossil). I would have thought it was self apparent that this is a desirable or even necessary thing to do, as part of the release process. Hope this is of some use, interest. Thanks for your time. Joseph
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
