Re: A deprecation policy
| От | Bruce Momjian |
|---|---|
| Тема | Re: A deprecation policy |
| Дата | |
| Msg-id | 200902120307.n1C370V10556@momjian.us обсуждение исходный текст |
| Ответ на | Re: A deprecation policy (Tom Lane <tgl@sss.pgh.pa.us>) |
| Список | pgsql-hackers |
Tom Lane wrote: > Peter Eisentraut <peter_e@gmx.net> writes: > > I have been thinking, with a semi-formal deprecation policy, we could > > make these decisions with more confidence. My proposed policy goes like > > this: > > I've been thinking about this for a couple of hours, and I keep coming > back to the conclusion that if we actually enforced a policy like this > it would kill Postgres development dead. It already takes more than a > year, on average, for a proposal to go from idea to out-in-the-field. > This policy would add another two years onto that for anything that > involved user-visible changes, which is most things. All but the most > persistent developers are simply going to go away and not bother trying > to shepherd their ideas through such a process. > > I can see the value of a more formal deprecation policy, but I think > it's gotta have a shorter time constant than this. Agreed. Consider the downside of having to support two different APIs for two releases, and document them. Yuck. There are some cases where a 2-release buffer is warranted, others where it is not. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: