Re: Our feature change policy

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Our feature change policy
Date: 2017-03-20 15:57:13
Message-ID: 20170320155713.GS9812@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom,

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> 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.

The rename of the binaries is case #2 above, at least as I was thinking
of it. I don't believe we are holding up progress in that case.

I was imagining the changes to pg_stat_activity as possibly falling
under #3/change, meaning that we'd wait for 5 years before actually
renaming those columns, which is part of why I was objecting to that
idea.

If we're able to make the change and provide backwards compatibility
then I think the main question is if it's worth it to do so and, if so,
when are we going to remove that backwards compatibility. If we don't
expect to ever be able to remove it, then that's an issue.

Thanks!

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rafia Sabih 2017-03-20 16:07:29 Re: Partition-wise join for join between (declaratively) partitioned tables
Previous Message Bruce Momjian 2017-03-20 15:51:44 Re: Our feature change policy