Sunday, August 23, 2009

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

@Adam - this sounds like a good idea - always more explicite information is good. But I think that the main purpose of policies is not informing (about what is the oldest version compatible with the current one) - but rather promising to follow a specific procedure when makig an icompatible change to give people time to adjust their code bases.