On Sun, Jan 13, 2008 at 08:46:03PM -0600, Rick Langschultz wrote: > I was wondering what would constitute the creation of SQLite 4.0?
IMO major implementation details changes are not necessarily a good rationale for bumping the major version number, not from a user's p.o.v. The authors might think it is though, and from a marketing p.o.v. it really, really might be (perception matters). If changing the major version number need not imply changing the C API prefix, then it's certainly easier to change the major version number. But I think developers are used to "sqlite3_" as the prefix now -- changing the major version number without changing that prefix will seem odd, but changing the prefix without substantive changes to the API will be gratuitous and very painful. If the 3.x C APIs became a stone around SQLite's neck and couldn't be incrementally fixed (by deprecating a small number of functions and adding a few new ones), then the time might be right for changing the prefix to sqlite4_. If the DB format had to change radically, then that too might be a good reason to change the major version number. My guess is that the 3.x APIs are plenty good enough that incremental evolution is far better than incompatible revolution, so I bet they are here to stay. Which means that if the major version number changes, then it'll be for marketing purposes. Nico -- ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
