Re: A deprecation policy

Peter,

> 3. In release N+2, if there were no protests in response to step 2,
> deprecated features are removed.

The main issue I can see with this is that most production sites only
upgrade once every 2-3 years. So they'd tend to miss warnings entirely.

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

I think the combination of a config file generator (in development now)
with a config file checker (something we could use anyway) would take
care of any config file issues.

I did actually give some thought to a config file converter, but the
number of options which are new, changed names, changed names and
changed meanings, changed options, or went away makes it an n^2 issue
and not really worth solving. Just tell the people to run the new
version of the config file generator.

The other thing we could use would be clearer documentation on this sort
of thing. That is, a single page in the docs which talks about what was
depreciated in specific versions. We kinda do this in the release
notes, but the notices often aren't that clear and are mixed in with a
lot of other stuff. Probably we should just clear this up in the
release notes.

--Josh