On 2015-10-08 6:03 PM, Richard Hipp wrote: > On 10/8/15, Darren Duncan <darren at darrenduncan.net> wrote: >> >> 2. If two successive versions have an overlapping but not equal API and >> file format, meaning that a subset of data files but not all of such >> readable or >> writeable by one version is readable and writeable by the other, or that a >> subset of code but not all of such that is correctly working against one >> version is likewise against the other, then the X at least should be >> different. >> This mainly is for releases that add or remove or change features. > > SQLite has the additional restriction that it does not break legacy. > It only adds new features. Otherwise, this seems to be a reasonable > description of what I am trying to achieve.
Thank you. In that case, I could generalize and simplify my proposal as follows... I would propose that with a W.X.Y semantic version scheme, the parts mean essentially [breaks-backward.breaks-forward.breaks-nothing], by which I mean: 1. If a newer version is incapable of doing something correctly that an older version is capable of doing correctly, such as supporting a particular API call with same behavior or such as reading or writing a particular file format, then the newer version should have a greater W than the older one. This is for when a backwards-compatibility break occurs such as because a feature was removed. The key point is a user can not simply take any code or file that works with the prior version and expect it to work without changes with the newer version. 2. Otherwise, if a newer version is capable of doing something correctly that an older version is incapable of doing correctly, such as supporting a particular API call with same behavior or such as reading or writing a particular file format, then the newer version should have a greater X than the older one. This is for when a forwards-compatibility break occurs such as because a feature was added. The key point is a user can not simply take any code or file that works with the newer version and expect it to work without changes with the prior version. 3. Otherwise, there are no known compatibility breaks, and the newer version only needs to have a greater Y than the older one. Users are free to move in both directions as long as any fixed (or created) bugs don't affect them. Note that while a backwards-compatibility break may happen in the same version as a forwards-compatibility break, such as a feature or API or file format substitution, this doesn't necessarily have to be the case; adding the new and removing the old could be done in separate versions. As an exception to the above definitions, when W is zero, then X is incremented for both backward-breaking and forward-breaking changes (while Y keeps its meaning); once W is greater than zero, that stops being the case. As with before, incrementing a number has no implication on the size of the change, just on how it is treated. For example, a large code refactoring that just affects performance but is non-breaking can still be a Y change. As with before, one can optionally increment a number position without being required to, such as for marketing reasons or to mark a maintenance branch. Note that the main break from my prior proposal is that incrementing W no longer needs to mean independent product or disjoint API etc, though that is allowed; if one wants a position to explicitly mean that only, then I would advocate having an extra digit, where a new leaving one, V, means disjoint, and the others have the meanings I said above. But given SQLite's goals, W may never increase anyway for decades, so we can save on that redundancy. -- Darren Duncan
