Re: Our feature change policy

On Mon, Mar 20, 2017 at 11:40:34AM -0400, Tom Lane 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.

I mentioned the problem of "confuse users" for #2. What delay are you
talking about? #3 and #4?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +