Tom Lane wrote: > Peter Eisentraut <pete...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
