On 2016-05-09 9:16 AM, Josh berkus wrote:
> Because there has never before been a "technical" reason for a major
> version number, so why is that the criterion now? People keep talking
> about breaking the file format, but since nobody has plans to do that in
> the next 2 releases, it's a stupid reason for waiting.
I would advocate changing to be aggressive with version number increases and
adapting a stricter semantic versioning.
See also what SQLite did recently as prior art:
https://www.sqlite.org/versionnumbers.html
Loosely speaking, have at least MAJOR.MINOR.PATCH.MATURITY components,
optionally more. MAJOR must be increased when a backwards-compatibility break
is made of any kind (such as removing a feature), otherwise MINOR must be
increased for any forwards-compatibility break (such as adding a feature),
otherwise PATCH must be increased for changes that shouldn't break any kind of
compatibility, except for fixing bugs or security holes where the old behavior
was not being relied on for any working uses. MATURITY means eg
alpha/beta/rc/production etc.
The version numbers reflect substitutability of versions. With respect to
Postgres this means both changes to the file format and changes to the API.
Any situation where the file format changes such that you can not simply stop
the server, swap the binaries, and restart and have it just work, is considered
a breaking change. If you can not swap to a newer version from an older one,
increment MAJOR; if you can do that but you can't switch back to the older one
from that newer, increment MINOR.
What I describe is simply situations where a version part MUST be increased;
they can also be increased at other times say for marketing reasons.
If a PATCH version accidentally broke something, another PATCH should be issued
which reverses it, so the promise to users on substitutability is maintained.
Note that I had been thinking about these matters more in depth as I adapted
that scheme for my own projects following SQLite doing so.
-- Darren Duncan