Re: 9.6 -> 10.0

On Mon, May 9, 2016 at 5:19 PM, Darren Duncan <darren(at)darrenduncan(dot)net>
wrote:

> On 2016-05-09 3:24 PM, Josh berkus wrote:
>
>> On 05/09/2016 03:18 PM, Darren Duncan wrote:
>>
>>> 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.
>>>
>>
>> That seems like that would be an argument against 10.0? Since we didn't
>> break backwards compat?
>>
>
> To be clear, I am talking about backwards compatibility in a holistic
> sense, both API *and* database cluster file format.
>
> 0. Start with the context of a standalone (not replicated) Postgres 9.5
> database cluster D1 and Postgres 9.5 binaries P1 and an application A1
> using those. A1 also includes the set of SQL/etc queries made manually by
> users.
>
> 1. Shutdown the Postgres servers P1, install new Postgres 9.6 binaries
> P2, start Postgres servers P2, this all without making any changes to D1 or
> A1 which includes not running pg_upgrade etc.
>
> 2. Use A1 for awhile without making any changes to it.
>
> 3. Shutdown the Postgres 9.6 servers P2, reinstall or use the previous
> Postgres 9.5 binaries P1, start Postgres servers P1.
>
> If despite switching to 9.6 and then back to 9.5 without making any
> changes to the application, everything just keeps working, then 9.6 is
> backwards-compatible with 9.5 in the holistic sense.
>
> When using 9.6 in the same way as 9.5 was used breaks the ability to use a
> database cluster as is with 9.5, backwards compatibility is broken.
>
>
​Default maturity is "production" - we introduce beta, etc... at the end of
a release cycle.

I'm highly doubtful we could go an entire year without introducing a
backward incompatibility - and to date we've never attempted to avoid doing
so. Thus what this proposal boils down to is:

Major.Patch[.Maturity]

Minor would never be incremented and would constitute harmful noise (it
would imply potential that doesn't practically exist) if specified
explicitly

IOW - We should just go to 10.0 in lieu of a 9.7 release, all then bug-fix
releases increment 10.1, 10.2, 10.3, etc..., and two years from now we
release 11.0

Semantic versioning has become more prevalent as more and more project have
either weekly/monthly cycles OR indefinite cycles where the increment will
depend on what just got patched at any given point in time. PostgreSQL
doesn't fit into either of those molds so 4+ semantic levels just doesn't
make sense.

​I'm sticking to my opinion that because of our present numbering scheme
and our 5-year support cycle we should increment major accordingly to those
project policies and should consider aligning advocacy on that time pulse
so certain aspects are emphasized during years 0,1,2,3,4 of the release
cycle. But, then again, I'm not close enough to this to say that what we
have now is even broken and warrants changing. All I have is an unproven
setup based upon logic and symmetry with only minimal practical experience
in advocacy.​

David J.