David G Johnston <david.g.johnston@gmail.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
