Re: Our feature change policy

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Bruce Momjian (bruce(at)momjian(dot)us) wrote:
>> 1. make the change now and mention it in the release notes
>> 2. #1, but also provide backward compatibility for 5+ years
>> 3. mark the feature as deprecated and remove/change it in 5+ years
>> 4. #3, but issue a warning for deprecated usage

> I don't generally feel like #1 is so rarely used (nor do I think it
> should be rare that we use it). With regard to #2, if we're going to do
> that, I'd really like to see us decide ahead of time on a point in time
> when we will remove the backwards-compatibility, otherwise it seems to
> live on forever. For my 2c, #3 should be reserved for things we are
> explicitly removing, not for things we're changing and we should do #4
> whenever possible in those cases because we're going to be removing it.

> Otherwise, #3 ends up being a case where we're holding up progress for
> years because we have to announce that we're going to deprecate
> something and then wait before we actually make whatever the change is.

Well, to what extent are we "holding up progress" in this particular
case? There is no other development work that's stalled by not renaming
these binaries. I think there should be some explicit accounting for
the impact of delay if we're going to try to formalize these decisions
better.

regards, tom lane