Breakage and deprecation cycle policies

I’ve just published Opaleye’s API breakage policy inspired by @chrisdone’s article on his Immutable Publishing Policy.

Does anyone know of any other articles on API breakage and deprecation cycle policies, in Haskell or any other language? It would be great to collect them together so we can learn from them and reduce the costs of change on Haskell users.

5 Likes

There is also the three release policy.

Nice article! I had not heard the term “flag day” before and am happy to learn it.

I have written a few blog entries on the topic:

In short, the three major versions policy has provided about 2~2.5 years of support for each major version. Based on my experience in industry, this seems quite short. I have worked at a place where Haskell developers were a minority and were kept busy with new projects, leaving little/no time for regular maintenance of previous projects. Time was allocated only when necessary, and many Haskell project “flag days” gave management the impression that Haskell projects are expensive to maintain.

I think that defining a support window based on time is preferable over one based on versions. Personally, I would like to support five years of tools and libraries. This is difficult in practice, however, when dependencies do not provide such a long span of support. Also, I have only had time to release small open source projects (so far), and my larger proprietary projects do not need to support multiple versions. With Opaleye, I imagine that you can better appreciate the difficulty/drawbacks of providing such long support.

2 Likes