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

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:

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.

--  Bruce Momjian  <bruce@momjian.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 +