On Tue, Jan 7, 2014 at 4:37 AM, Jan Nijtmans <jan.nijtm...@gmail.com> wrote:
> 2014/1/7 Joseph R. Justice <jayare...@gmail.com>: > > > 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? > > It's fully up to the Fossil-devs what should be the minimum SQLite > version Fossil is supposed to work with, and when this minimum > is updated to higher SQLite versions. My proposal is based on > a SQLite 3.8.3 release in February 2014. If that changes or if > the Fossil developers want to move forward faster than that, > it is very well possible. For Cygwin that wouldn't be a problem, as > SQLite 3.8.2 is already available now as Cygwin package. For > other OS distributions I don't know, I'll leave it to others to comment on > that. > I fully agree that it's up to the Fossil upstream devs as to what should be the minimum version of SQLite supported with any given release version of Fossil, and also as to when the minimum version of SQLite supported should be changed (and what it should be changed to). My thought here was that the devs (or at least Dr. Hipp as the architect) seem to desire to make the minimum supported version of SQLite be 3.8.2 *now*. If that's so, why make them wait for a full release version of Fossil (e.g. until development begins for Fossil 1.29) before they can make that change? After all, it's the distributions' problem to provide the SQLite library version Fossil upstream requires, or else to patch Fossil to work with whatever version of SQLite the distribution is willing to provide. (But... See below for a countervailing point.) Ummm... As a sort of aside, I'd like to point out one thing here for the benefit of the Fossil upstream devs, on the off chance they have not yet considered it. It's something I think is a sort of corollary / consequence of what we're talking about that's obvious when you think about it carefully, but which might be easy to overlook at a first quick glance. (Ron Wilson's message kind of refers to this, but does not state it explicitly.) I'd like to explicitly state it for the record. Okay. Again, Fossil upstream devs ARE NOT REQUIRED to support using a given release version of Fossil with any random old version of SQLite a end-user (or distribution) wishes to use. The upstream devs have the right to say "We only support using this release version of Fossil with at least version XY.ZZ.Y of SQLite, and will not support using this version of Fossil with any older version of SQLite". The upstream devs are (in general) all unpaid volunteers, and as such have the right to set whatever limit on support they want to set. However... Just as are the Fossil upstream devs, the developers / packagers of a given FOSS Unix/Linux distribution *are* *also* (in general) unpaid volunteers, and as such *do* *also* have the right to set whatever limit on support *they* (the distribution developers / packagers) want to set! In particular, *they* have the right to say "We only support SQLite with a maximum release version of BL.EG.H, and any software which requires a version of SQLite more recent than this version is not supportable by us and we will not package and distribute it in our current version of the distribution". The distributions ARE NOT REQUIRED to support or distribute software which needs any random new version of SQLite a developer wishes to use! This means that if the minimum supported version of SQLite the Fossil upstream devs require for their new release version is XY.ZZ.Y, and the maximum supported version of SQLite the distribution developers will provide for their current release version of the distro is BL.EG.H, and XY.ZZ.Y > BL.EG.H, then the new release version of Fossil will not be made available for that version of the distribution (at least until they raise their maximum supported version of SQLite), and the new release version of Fossil may not even be *useable* on that version of the distribution! Insofar as the Fossil upstream devs *desire* their current version of Fossil to be packaged and distributed by the various distributions (as opposed to requiring end-users to compile / install Fossil on their own), *this* is the problem of Fossil upstream -- to limit themselves to using only versions of libraries which are actually available within the various distributions (the major ones anyway) they want to have distribute their software. Now, I'll grant that Fossil, by its intrinsic nature and primary intended target audience (e.g. that it is a software development tool intended for use by software developers), isn't as constrained by this as would be an application intended for use by typical non-technical end-users, such as say an office productivity application or a financial / bookkeeping application, or a game, or whatever. Fossil can say "you're a developer, you know how to compile software on your own, just handle it" and expect a sufficiently motivated end user to do just that. However, insofar as the Fossil upstream devs wish Fossil to also be used by more normal and non-technical end users, and insofar as they wish Fossil to be made available by the various distributions, this *is* something they have to take into consideration! They may have to constrain themselves to *not* use the latest and greatest bleeding-edge software available if they wish to be available via distributions which do not support bleeding-edge software. (As to if this *should* be a consideration for Fossil upstream, or how *strong* a consideration it should be for them, I decline to express an opinion concerning -- this is for the upstream devs to decide amongst themselves.) Ummm... One other quite possibly naive question. I browsed in the Fossil sources briefly related to the tag you mentioned previously, the sqlite-min-to-3.7.17 tag, and if I'm understanding what I see correctly, you're doing the check for the minimum supported version based on if SQLite is reporting if specific capabilities are available, apparently on the grounds that if a given capability is available then that means the version of SQLite available is at least X. Now, if that's the coding style and philosophy Fossil uses, then so be it. I'm certainly not in a position to say it's wrong; I realize there might be a very good reason which I simply haven't considered for doing it that way. However, I *do* note that SQLite documents ways to check, at compile time and/or run time, what version the SQLite library believes it is. Would this be of any use in terms of Fossil determining if the version of SQLite available is sufficient for Fossil's purposes? See http://www.sqlite.org/c3ref/c_source_id.html (SQLite C Interface: Compile-Time Library Version Numbers); http://www.sqlite.org/c3ref/libversion.html (SQLite C Interface: Run-Time Library Version Numbers); and http://www.sqlite.org/lang_corefunc.html#sqlite_version (SQLite Query Language: Core Functions) for more information. > > 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. > > I agree. It would be possible to make a Fossil release at any time, > independent from SQLite. As long as Fossil doesn't use any > SQLite features which are not available yet in the latest SQLite > release, either the latest SQLite amalgamation could be shipped > with it, either the latest SQLite trunk amalgamation. The latter > choice means more risk, however small in practice. > I think you are saying here that it would be reasonable for the Fossil devs, for a *release* (e.g. supposed to be stable / production quality) version of Fossil, to specify using and/or provide as an embedded code copy *either* a release version of SQLite *or* a development (e.g. could change, isn't guaranteed to be stable / production quality) version of SQLite? (I assume "the latest SQLite trunk amalgamation" means a development version of SQLite.) I disagree. I'm pretty sure that, if you ask any significant distribution if they are willing to ship, as part of a *stable* and *supported* version of the distribution (as opposed to an "in development" and unstable version of the distribution), a in-development version of a library such as SQLite, they will usually if not always say "No, we are not, we are only willing to ship stable release versions of this library with stable release versions of our distribution". So, insofar as you care about Fossil being provided by distributions as part of their stable release, then I would not make Fossil depend on a version of SQLite that is not a stable release version. Now, for *development* versions of Fossil, I think it is perfectly reasonable and appropriate for the Fossil devs to use a development version of SQLite if they wish to! That makes it easier and faster for Fossil to be able to make use of new features provided by the latest version of SQLite once that version is marked as stable, Fossil doesn't have to wait for the stable version of SQLite to be released to start writing code that will work with that version. But, for *release* versions of Fossil, this is not reasonable or appropriate, at least if Fossil wants any distribution to distribute it. 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
