On Wed, Oct 7, 2015 at 2:06 PM, Jaroslaw Staniek <staniek at kde.org> wrote:
> > > On 7 October 2015 at 17:39, Richard Hipp <drh at sqlite.org> wrote: > >> On 10/7/15, Jaroslaw Staniek <staniek at kde.org> wrote: >> > ? would you elaborate what? is the >> > benefit of using x.y.z versioning scheme if so many new features come to >> > the "z" release? >> >> That's the versioning scheme that has been used by SQLite for 15 >> years. Back when it was adopted, 15 years ago, it was certainly *not* >> the case that 99.9% of software did something different. In fact, 15 >> years ago, the current SQLite versioning scheme was rather common. >> >> The community seems to want the second number (current 8) to increment >> every time a new feature is added to SQLite. I will take your request >> under advisement. Realize, however, that had the current preferred >> number scheme been used for SQLite from the beginning, the next >> release would be called 3.112. >> >> ? > Thanks so much, such a linear version would be appreciated. > > PS: E.g. equivalent of the recent 3.8.11.1 would be 3.y.1 > -- I think versions x.y.z.v would be no longer needed. > Really, the SQLite3 versioning isn't that far off from Semantic Versioning. Instead of MAJOR.MINOR.PATCH we have FORMAT.MAJOR.MINOR.PATCH. Admittedly, the MAJOR.MINOR parts are a *little* intermingled, but reading through the release history it is fairly clear that a change in MAJOR usually results from MAJOR new functionality, MINOR is for relatively MINOR new functionality, and PATCH is apparently never used outside that context. While I personally have no complaints with people who use Semantic Versioning, I don't see SQLite versioning as being horribly incompatible with it. In fact, if I were making the decision, I'd keep the current versioning. -- Scott Robison
