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

Noah Misch-2 wrote
> On Sat, Nov 29, 2014 at 02:09:09PM -0500, Tom Lane wrote:
>> Noah Misch <

> noah@

> > writes:
>> > Revert "Add libpq function PQhostaddr()."
>> > This reverts commit 9f80f4835a55a1cbffcda5d23a617917f3286c14. The
>> > function returned the raw value of a connection parameter, a task
>> served
>> > by PQconninfo(). The next commit will reimplement the psql \conninfo
>> > change that way. Back-patch to 9.4, where that commit first appeared.
>>
>> I confess to not having been paying too much attention to your discussion
>> with Fujii over the holiday, but isn't it a bit too late to be making
>> client-API-breaking changes in 9.4? I would have been fine with this
>> before RC1 went out, but once we do that, the branch should be treated
>> as released.
>
> 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.

David J.

--
View this message in context: http://postgresql.nabble.com/Re-COMMITTERS-pgsql-Revert-Add-libpq-function-PQhostaddr-tp5828660p5828672.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.