Re: Our feature change policy

On Mon, Mar 20, 2017 at 8:57 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:

> 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 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.
>

Which ends up boiling down to:

A. Make a change and document it in the release notes

B. If applicable, and desired, provide a 5 year backward​ compatibility
deprecation period (i.e., 3 =>[implies] 2). Generally 2 => 3 but the
deprecation period is undefined.

C. Optionally, if deprecating, provide explicit warnings when the
deprecated feature is used

Guidelines for when to desire the 5 year period would be helpful. And also
acknowledge that we may wish to choose a shorter period of time, or
institute immediate removal, at our discretion.

Nothing says we cannot go longer than 5 years but given our support policy
I would say that we'd rarely desired to do so intentionally - the burden of
proof falling to those who would want to keep something longer.

David J.