2014/1/7 Joseph R. Justice <jayare...@gmail.com>:
> 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.
Yes, sure, that's exactly what I mean.
> 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 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.
Regards,
Jan Nijtmans
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
