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
In related news mst gives an overview of techniques that can be used for maintaining back-compat - sometimes these are really simple things.