On 26/02/2009 11:55 AM, Roger Binns wrote: Hi Roger,
> John Machin wrote: >> In >> that situation, the next question to arise would be "What other >> currently-documented features must I avoid?" > > The usual solution is for documentation for each API to include version > information about when it was introduced. > > In the short term you can go to http://www.sqlite.org/cvstrac/timeline > and then scroll to the bottom of the page. If you set number of days to > 1,500 then you'll get the last 4 years of history. That sounds good. I'll try it out later. > However do note that the project makes it trivial to update to newer > versions. Best practise is to use the amalgamation directly in your > project which means upgrading is as simple as updating one file. I agree that SQLite makes it trivial to update to newer versions -- if being used directly in C; via language X's DBAPI interface and Linux distro Y might be another story :-) However my point is that many people are prevented for various reasons for *deploying* that new version into production, and are constrained to remain on some earlier version of SQLite. To quote the person asking about replace(): """ Unfortunately though I don't have the option of updating it, since I am using it on a very widespread set of machines which I don't have root privileges on... """ My question was along the lines of making it easier for such a person to determine what set of features they should avoid when writing code. Cheers, John _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
