On Thu, Oct 8, 2015 at 10:21 AM, Richard Hipp <drh at sqlite.org> wrote:
> To look at it another way, in version X.Y.Z, it has always been the > case and will remain the case that Y is incremented for major changes > and Z is incremented for minor changes. The proposed policy change is > to alter the definition of "major" and "minor" such that *anything* > other than a simple bug fix of a few lines is considered a "major" > change. Formerly, "major" changes were things like adding WAL mode or > rewriting the query planner, and adding WITHOUT ROWID tables, CTEs, > and partial indexes were all considered "minor" changes. > > It all really boils down to this: What is the difference between a > "major" and a "minor" change? > A "minor" change has to my way of thinking always been about "this fixes something that wasn't working as intended". One potential downside (based on a previous comment in this thread) I can see to going to a more "semantic versioning compliant" model is the expectation that some people might have that every 3.y release will be maintained with bug fixes / z level patches. For example: 3.1.0 is released 3.1.1 fixes a bug in 3.1 3.2.0 is released with new features. 3.2.1 fixes a bug originally introduced in 3.1.0 Some people are going to expect that bug fix to be back ported into the 3.1 branch and have a 3.1.2 release cut from it. -- Scott Robison
