"Scott Robison" wrote...
> 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. I agree. Keep the same versioning schema. jic
