Let's write some deprecation policies

Sebastian writes about version numbers and backwards compatibility and asks:

Should a project have deprecation policies as soon as it hits CPAN with a development release?

I think the answer should be yes - there should always be a deprecation policy. But this deprecation policy does not need to be the full monty of always keeping the backcompat to at least one major version, using strict deprecation cycles etc - it just needs to be stated explicitely and not relying on the version numbering convention as they are not really universal. There is no negative side to putting a few sentences into the docs, only a bit work to formulate them. And here is my idea:

Let's write some deprecation policies

Let's have a list of well formulated policies covering as much as we can of possible circumstances (from experimental to mature, and from one-person projects to team work) that could be copied to the CPAN distribution docs with minimal effort. For the start - here are some ideas:

• Experimental - no policies at all, use at your own risk
  
• Experimental with mailing list announcements of new versions and promise to take into account problems encountered by people testing the new code
  
• Backcompat to one version, with a specific minimal time between versions
  
• Backcompat to one major version, with a specific minimal time between major releases
  

Update:
In related news mst gives an overview of techniques that can be used for maintaining back-compat - sometimes these are really simple things.