Re: [HACKERS] Our feature change policy
| От | David G. Johnston |
|---|---|
| Тема | Re: [HACKERS] Our feature change policy |
| Дата | |
| Msg-id | CAKFQuwavVzmn2_760dXErH0rXNk297ZTcyLw6e4D7PkACgiC7g@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Our feature change policy (Stephen Frost <sfrost@snowman.net>) |
| Список | pgsql-hackers |
Tom,
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > * Bruce Momjian (bruce@momjian.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.
В списке pgsql-hackers по дате отправления: