Re: [HACKERS] Our feature change policy - Mailing list pgsql-hackers

Bruce,

* Bruce Momjian (bruce@momjian.us) wrote:
> On Sun, Mar 19, 2017 at 04:15:09PM -0400, Tom Lane wrote:
> > Stephen Frost <sfrost@snowman.net> writes:
> > > If we take your approach to its logical conclusion then we should be
> > > planning to maintain all user-facing deprecated features for as long as
> > > there is a version where it exists in a non-deprecated fashion, in other
> > > words for 5 years, if we assume that script authors only care about
> > > supporting as far back as we do, which I'm not entirely sure is a great
> > > assumption to begin with, but I'd say it's at least a minimum.
> >
> > Well, that is definitely a straw man (as you admit later).  I don't want
> > to go there either.  Where to draw the line has to be a case-by-case
> > decision, though.  In this case the amount of effort involved in providing
> > backwards compatibility is pretty minimal, and the project has failed to
> > provide any warning to users that this is something we might choose to
> > break in future, so it seems to me that we ought to provide compatibility
> > for awhile.  If somebody bitches that we broke their script in v15, we'll
> > be in a much better position if we can point to five years' worth of
> > deprecation notices than if we just have to say "tough, we felt like
> > breaking your script so we did it".
>
> [ I have started a new thread for this topic but kept the above quote.]
>
> We keep re-litigating changes, either with pg_xlog, binaries, or
> pg_stat_activity, and at some point we need to settle on a
> policy.  The usual "change" options are:

Agreed.

> 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
>
> What causes us to choose different outcomes?  #1 is usually for
> rarely-used features or features that are dangerous.  #2 is usually for
> popular features where backward compatibility will not confuse users,
> e.g. this is not possible for renaming pg_stat_activity columns because
> SELECT * FROM pg_stat_activity will show the old and new columns.  #3 is
> for rarely-used features or features we don't want --- sometimes we go
> long over five years and still can't remove something because we don't
> have a fully-featured replacement, e.g. contrib/xml2.  #4 is for changes
> that could affect data validity or are hard to detect, e.g. the
> standard-conforming string change.
>
> Is this accurate?  If so we can write this down and avoid the +1/-1
> re-litigating every time we want to change something, or at least have a
> more focused conversation on the issues related to the change.

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.

Thanks!

Stephen