Our feature change policy

On Sun, Mar 19, 2017 at 04:15:09PM -0400, Tom Lane wrote:
> Stephen Frost <sfrost(at)snowman(dot)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(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 +