On 10/8/15, Stephen Chrzanowski <pontiac76 at gmail.com> wrote:
>
> What the minor and build versions mean is subject to change and offer an
> air of confusion. With a 3.{Date} version, you get a concrete "This is the
> day the product was built with all features and known bug fixes". And it'd
> be just as easy for people to report "Between 201510081205 and 201512101500
> I have this problem..." Bit harder to read, come to think of it.....
SQLite already offers date-based versioning as an alternative. See
the sqlite3_sourceid() interface and the SQLITE_SOURCE_ID macro, both
of which begin with the ISO8601 date.
The sqlite3_libversion_number() interface and the
SQLITE_VERSION_NUMBER macro depend on the old-style X.Y.Z version
numbers though. And lots of legacy code depends on those interfaces,
so they need to continue to be supported moving forward.
--
D. Richard Hipp
drh at sqlite.org
