Re: Question and suggestion about application binary compatibility policy

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
Cc: "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Question and suggestion about application binary compatibility policy
Date: 2016-06-23 13:26:45
Message-ID: 20160623132645.GD21246@momjian.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 23, 2016 at 06:42:57AM +0000, Tsunakawa, Takayuki wrote:
> > From: Bruce Momjian [mailto:bruce(at)momjian(dot)us]
> > We have this text in src/tools/RELEASE_CHANGES:
> > ...
> > This is saying running against a mismatched minor version should be fine
> > for a binary.
>
> Thanks for a good rationale.
>
>
> > I know this thread is old but it bounced around a lot of ideas. I think
> > there are some open questions:
> >
> > * Will a new application link against an older minor-version libpq?
> > * Will an old application link against a newer minor-version libpq?
>
> The former does not always hold true, if the application uses a new libpq function which is not in an old miner-version. But I think the backward-compatibility is enough.

Yes, I think that is correct, and I think that is covered in the file
posted:

Adding a new function should NOT force an increase in the major version
number.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2016-06-23 13:30:01 Re: Bug in to_timestamp().
Previous Message hari.prasath 2016-06-23 12:52:33 Extract Jsonb key and values