Re: A deprecation policy

On Wed, 11 Feb 2009 09:47:25 +0200
Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> 1. In release N, an interface is declared "obsolete", which means that
> [...]
> 2. In release N+1, obsolete interfaces are declared "deprecated", which

I like the idea but aren't these two terms reversed? In fact, isn't
"obsolete" your third stage? Certainly "obsolete" suggests that it
can't be used any longer. I'm not sure what the second stage should be
called in that case though.

Also, does the progression through releases have to be absolute? Can
something stay in "deprecated" for two releases if it is felt that
people need more time?

> Also, consider that we want to get in-place upgrade working, so
> essential interfaces such as basic commands and configuration files
> should at least be able to limp along after being moved to version N+1.

Yes.

> Altering semantics of log_filename without placeholder (under
> discussion): Release 8.4: Declare current behavior obsolete. Release
> 8.5: Deprecation warning. Release 8.6: Implement whatever new behavior
> we like.

But whatever works in 8.6 would also have to work in 8.4, right? We
can't call something "deprecated" or "obsolete" without allowing the
user to update their code/configuration right away.

> I would also extend this system to removed configuration settings, e.g.,
> max_fsm_*. We should make these deprecated for one release, so (1)
> configuration files can be upgraded without manual work (relevant to
> in-place upgrade), and (2) users are alerted that their carefully
> crafted configuration might need a review.

As long as they can remove the item giving the warning right away.

--
D'Arcy J.M. Cain <darcy(at)druid(dot)net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 425 1212 (DoD#0082) (eNTP) | what's for dinner.