Re: 10.0

David G. Johnston <david.g.johnston@gmail.com>

From: "David G. Johnston" <david.g.johnston@gmail.com>

To: Mark Dilger <hornschnorter@gmail.com>

Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Josh berkus <josh@agliodbs.com>, Tom Lane <tgl@sss.pgh.pa.us>, David Fetter <david@fetter.org>, Thom Brown <thom@linux.com>, Dave Page <dpage@pgadmin.org>, Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>

Date: 2016-05-14T03:26:49Z

Lists: pgsql-hackers

On Fri, May 13, 2016 at 10:18 PM, Mark Dilger <hornschnorter@gmail.com>
wrote:

>
> My main concern is that a commitment to never, ever break backwards
> compatibility is a commitment to obsolescence.

You started this sub-thread with:

"If I understand correctly..."

I'm not sure that you do...

Our scheme is, in your terms, basically:

<major>.micro

where <major> is a decimal.

You cannot reason about the whole and fraction portions of the decimal
independently.

When <major> changes backward compatibility can be broken - with respect to
both API and implementation.

It therefore makes sense to
> reserve room in the numbering scheme to be clear and honest about when
> backwards compatibility has been broken.  The major number is the normal
> place to do that.

I'm not convinced there is enough risk here to compromise the present in
order to accommodate some unknown scenario that may never even come to
pass.

David J.