Re: [COMMITTERS] pgsql: Revert "Add libpq function PQhostaddr()."

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [COMMITTERS] pgsql: Revert "Add libpq function PQhostaddr()."
Date: 2014-11-30 03:12:41
Message-ID: 10183.1417317161@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers pgsql-hackers

David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> Noah Misch-2 wrote
>> I had considered that, and one could make a reasonable case for living
>> with the new symbol on that basis. For the release candidate stage to
>> have value, though, the "treat as released" principle must not be
>> absolute. I regret not noticing the problem earlier.

> Then the question becomes whether any backward incompatibility introduced in
> an RC release necessitates another RC release instead of going live with the
> next revision. I'll go with the idea that all betas and RC versions can
> have API changes but the release immediately preceding the actual release
> should not be allowed to do so. People who have tested their code on the
> most recent RC prior to release should be assured that when the final
> version is released that all API testing done previously is good.

> The RC is final release phase that our vendor community can use to polish
> their applications before end users are able to download the functionally
> equivalent final release. We do not want to force our vendors to have to
> finalize their 9.4 support in the short period between announcing the final
> release and it being made available in repositories.

> It is just as valid to insist that there will only be a single RC in which
> case API changes must not occur. But unles the community feels too burdened
> but an unbounded RC policy the ability to fix problems even during the RC
> phase seems valuable. These should be minor things so the biggest cost is
> the added RC release and not so much that applications end to be modified.

Well, personally, as one of the people on whom the burden of an extra RC
release would fall, let me make it clear that there will *not* be an RC2
release just for this. If the community consensus is that this change
would require us to do an RC2, it's going to get reverted.

regards, tom lane

In response to

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2014-11-30 17:21:09 pgsql: Fix minor bugs in commit 30bf4689a96cd283af33edcdd6b7210df3f20cd
Previous Message David G Johnston 2014-11-29 21:55:30 Re: [COMMITTERS] pgsql: Revert "Add libpq function PQhostaddr()."

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2014-11-30 04:46:57 Re: How about a option to disable autovacuum cancellation on lock conflict?
Previous Message Noah Misch 2014-11-30 02:02:04 Re: Securing "make check" (CVE-2014-0067)